Backmerge v6.12-rc6 of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next (30169bb6) · Commits · git / linux-net

.mailmap

+14 −2

Original line number	Diff line number	Diff line
		@@ -73,6 +73,8 @@ Andrey Ryabinin <ryabinin.a.a@gmail.com> <aryabinin@virtuozzo.com>
		Andrzej Hajda <andrzej.hajda@intel.com> <a.hajda@samsung.com>
		André Almeida <andrealmeid@igalia.com> <andrealmeid@collabora.com>
		Andy Adamson <andros@citi.umich.edu>
		Andy Chiu <andybnac@gmail.com> <andy.chiu@sifive.com>
		Andy Chiu <andybnac@gmail.com> <taochiu@synology.com>
		Andy Shevchenko <andy@kernel.org> <andy@smile.org.ua>
		Andy Shevchenko <andy@kernel.org> <ext-andriy.shevchenko@nokia.com>
		Anilkumar Kolli <quic_akolli@quicinc.com> <akolli@codeaurora.org>
		@@ -197,18 +199,23 @@ Elliot Berman <quic_eberman@quicinc.com> <eberman@codeaurora.org>
		Enric Balletbo i Serra <eballetbo@kernel.org> <enric.balletbo@collabora.com>
		Enric Balletbo i Serra <eballetbo@kernel.org> <eballetbo@iseebcn.com>
		Erik Kaneda <erik.kaneda@intel.com> <erik.schmauss@intel.com>
		Eugen Hristev <eugen.hristev@collabora.com> <eugen.hristev@microchip.com>
		Eugen Hristev <eugen.hristev@linaro.org> <eugen.hristev@microchip.com>
		Eugen Hristev <eugen.hristev@linaro.org> <eugen.hristev@collabora.com>
		Evgeniy Polyakov <johnpol@2ka.mipt.ru>
		Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> <ezequiel@collabora.com>
		Faith Ekstrand <faith.ekstrand@collabora.com> <jason@jlekstrand.net>
		Faith Ekstrand <faith.ekstrand@collabora.com> <jason.ekstrand@intel.com>
		Faith Ekstrand <faith.ekstrand@collabora.com> <jason.ekstrand@collabora.com>
		Fangrui Song <i@maskray.me> <maskray@google.com>
		Felipe W Damasio <felipewd@terra.com.br>
		Felix Kuhling <fxkuehl@gmx.de>
		Felix Moeller <felix@derklecks.de>
		Fenglin Wu <quic_fenglinw@quicinc.com> <fenglinw@codeaurora.org>
		Filipe Lautert <filipe@icewall.org>
		Finn Thain <fthain@linux-m68k.org> <fthain@telegraphics.com.au>
		Fiona Behrens <me@kloenk.dev>
		Fiona Behrens <me@kloenk.dev> <me@kloenk.de>
		Fiona Behrens <me@kloenk.dev> <fin@nyantec.com>
		Franck Bui-Huu <vagabon.xyz@gmail.com>
		Frank Rowand <frowand.list@gmail.com> <frank.rowand@am.sony.com>
		Frank Rowand <frowand.list@gmail.com> <frank.rowand@sony.com>
		@@ -276,7 +283,7 @@ Jan Glauber <jan.glauber@gmail.com> <jglauber@cavium.com>
		Jan Kuliga <jtkuliga.kdev@gmail.com> <jankul@alatek.krakow.pl>
		Jarkko Sakkinen <jarkko@kernel.org> <jarkko.sakkinen@linux.intel.com>
		Jarkko Sakkinen <jarkko@kernel.org> <jarkko@profian.com>
		Jarkko Sakkinen <jarkko@kernel.org> <jarkko.sakkinen@tuni.fi>
		Jarkko Sakkinen <jarkko@kernel.org> <jarkko.sakkinen@parity.io>
		Jason Gunthorpe <jgg@ziepe.ca> <jgg@mellanox.com>
		Jason Gunthorpe <jgg@ziepe.ca> <jgg@nvidia.com>
		Jason Gunthorpe <jgg@ziepe.ca> <jgunthorpe@obsidianresearch.com>
		@@ -300,6 +307,11 @@ Jens Axboe <axboe@kernel.dk> <axboe@fb.com>
		Jens Axboe <axboe@kernel.dk> <axboe@meta.com>
		Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
		Jernej Skrabec <jernej.skrabec@gmail.com> <jernej.skrabec@siol.net>
		Jesper Dangaard Brouer <hawk@kernel.org> <brouer@redhat.com>
		Jesper Dangaard Brouer <hawk@kernel.org> <hawk@comx.dk>
		Jesper Dangaard Brouer <hawk@kernel.org> <jbrouer@redhat.com>
		Jesper Dangaard Brouer <hawk@kernel.org> <jdb@comx.dk>
		Jesper Dangaard Brouer <hawk@kernel.org> <netoptimizer@brouer.com>
		Jessica Zhang <quic_jesszhan@quicinc.com> <jesszhan@codeaurora.org>
		Jilai Wang <quic_jilaiw@quicinc.com> <jilaiw@codeaurora.org>
		Jiri Kosina <jikos@kernel.org> <jikos@jikos.cz>

CREDITS

+27 −27

Original line number	Diff line number	Diff line
		@@ -1358,10 +1358,6 @@ D: Major kbuild rework during the 2.5 cycle
		D: ISDN Maintainer
		S: USA

		N: Gerrit Renker
		E: gerrit@erg.abdn.ac.uk
		D: DCCP protocol support.

		N: Philip Gladstone
		E: philip@gladstonefamily.net
		D: Kernel / timekeeping stuff
		@@ -1677,11 +1673,6 @@ W: http://www.carumba.com/
		D: bug toaster (A1 sauce makes all the difference)
		D: Random linux hacker

		N: James Hogan
		E: jhogan@kernel.org
		D: Metag architecture maintainer
		D: TZ1090 SoC maintainer

		N: Tim Hockin
		E: thockin@hockin.org
		W: http://www.hockin.org/~thockin
		@@ -1697,6 +1688,11 @@ D: hwmon subsystem maintainer
		D: i2c-sis96x and i2c-stub SMBus drivers
		S: USA

		N: James Hogan
		E: jhogan@kernel.org
		D: Metag architecture maintainer
		D: TZ1090 SoC maintainer

		N: Dirk Hohndel
		E: hohndel@suse.de
		D: The XFree86[tm] Project
		@@ -1872,6 +1868,10 @@ S: K osmidomkum 723
		S: 160 00 Praha 6
		S: Czech Republic

		N: Seth Jennings
		E: sjenning@redhat.com
		D: Creation and maintenance of zswap

		N: Jeremy Kerr
		D: Maintainer of SPU File System

		@@ -2188,19 +2188,6 @@ N: Mike Kravetz
		E: mike.kravetz@oracle.com
		D: Maintenance and development of the hugetlb subsystem

		N: Seth Jennings
		E: sjenning@redhat.com
		D: Creation and maintenance of zswap

		N: Dan Streetman
		E: ddstreet@ieee.org
		D: Maintenance and development of zswap
		D: Creation and maintenance of the zpool API

		N: Vitaly Wool
		E: vitaly.wool@konsulko.com
		D: Maintenance and development of zswap

		N: Andreas S. Krebs
		E: akrebs@altavista.net
		D: CYPRESS CY82C693 chipset IDE, Digital's PC-Alpha 164SX boards
		@@ -3191,6 +3178,11 @@ N: Ken Pizzini
		E: ken@halcyon.com
		D: CDROM driver "sonycd535" (Sony CDU-535/531)

		N: Mathieu Poirier
		E: mathieu.poirier@linaro.org
		D: CoreSight kernel subsystem, Maintainer 2014-2022
		D: Perf tool support for CoreSight

		N: Stelian Pop
		E: stelian@popies.net
		P: 1024D/EDBB6147 7B36 0E07 04BC 11DC A7A0 D3F7 7185 9E7A EDBB 6147
		@@ -3300,6 +3292,10 @@ S: Schlossbergring 9
		S: 79098 Freiburg
		S: Germany

		N: Gerrit Renker
		E: gerrit@erg.abdn.ac.uk
		D: DCCP protocol support.

		N: Thomas Renninger
		E: trenn@suse.de
		D: cpupowerutils
		@@ -3576,11 +3572,6 @@ D: several improvements to system programs
		S: Oldenburg
		S: Germany

		N: Mathieu Poirier
		E: mathieu.poirier@linaro.org
		D: CoreSight kernel subsystem, Maintainer 2014-2022
		D: Perf tool support for CoreSight

		N: Robert Schwebel
		E: robert@schwebel.de
		W: https://www.schwebel.de
		@@ -3771,6 +3762,11 @@ S: Chr. Winthersvej 1 B, st.th.
		S: DK-1860 Frederiksberg C
		S: Denmark

		N: Dan Streetman
		E: ddstreet@ieee.org
		D: Maintenance and development of zswap
		D: Creation and maintenance of the zpool API

		N: Drew Sullivan
		E: drew@ss.org
		W: http://www.ss.org/
		@@ -4286,6 +4282,10 @@ S: Pipers Way
		S: Swindon. SN3 1RJ
		S: England

		N: Vitaly Wool
		E: vitaly.wool@konsulko.com
		D: Maintenance and development of zswap

		N: Chris Wright
		E: chrisw@sous-sol.org
		D: hacking on LSM framework and security modules.

Documentation/admin-guide/LSM/ipe.rst

+5 −2

Original line number	Diff line number	Diff line
		@@ -223,7 +223,10 @@ are signed through the PKCS#7 message format to enforce some level of
		authorization of the policies (prohibiting an attacker from gaining
		unconstrained root, and deploying an "allow all" policy). These
		policies must be signed by a certificate that chains to the
		``SYSTEM_TRUSTED_KEYRING``. With openssl, the policy can be signed by::
		``SYSTEM_TRUSTED_KEYRING``, or to the secondary and/or platform keyrings if
		``CONFIG_IPE_POLICY_SIG_SECONDARY_KEYRING`` and/or
		``CONFIG_IPE_POLICY_SIG_PLATFORM_KEYRING`` are enabled, respectively.
		With openssl, the policy can be signed by::

		openssl smime -sign \
		-in "$MY_POLICY" \
		@@ -266,7 +269,7 @@ in the kernel. This file is write-only and accepts a PKCS#7 signed
		policy. Two checks will always be performed on this policy: First, the
		``policy_names`` must match with the updated version and the existing
		version. Second the updated policy must have a policy version greater than
		or equal to the currently-running version. This is to prevent rollback attacks.
		the currently-running version. This is to prevent rollback attacks.

		The ``delete`` file is used to remove a policy that is no longer needed.
		This file is write-only and accepts a value of ``1`` to delete the policy.

Documentation/admin-guide/pm/cpufreq.rst

+10 −10

Original line number	Diff line number	Diff line
		@@ -425,8 +425,8 @@ This governor exposes only one tunable:

		``rate_limit_us``
		Minimum time (in microseconds) that has to pass between two consecutive
		runs of governor computations (default: 1000 times the scaling driver's
		transition latency).
		runs of governor computations (default: 1.5 times the scaling driver's
		transition latency or the maximum 2ms).

		The purpose of this tunable is to reduce the scheduler context overhead
		of the governor which might be excessive without it.
		@@ -474,17 +474,17 @@ This governor exposes the following tunables:
		This is how often the governor's worker routine should run, in
		microseconds.

		Typically, it is set to values of the order of 10000 (10 ms). Its
		default value is equal to the value of ``cpuinfo_transition_latency``
		for each policy this governor is attached to (but since the unit here
		is greater by 1000, this means that the time represented by
		``sampling_rate`` is 1000 times greater than the transition latency by
		default).
		Typically, it is set to values of the order of 2000 (2 ms). Its
		default value is to add a 50% breathing room
		to ``cpuinfo_transition_latency`` on each policy this governor is
		attached to. The minimum is typically the length of two scheduler
		ticks.

		If this tunable is per-policy, the following shell command sets the time
		represented by it to be 750 times as high as the transition latency::
		represented by it to be 1.5 times as high as the transition latency
		(the default)::

		# echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) > ondemand/sampling_rate
		# echo `$(($(cat cpuinfo_transition_latency) * 3 / 2)) > ondemand/sampling_rate

		``up_threshold``
		If the estimated CPU load is above this value (in percent), the governor

Documentation/core-api/protection-keys.rst

+30 −8

Original line number	Diff line number	Diff line
		@@ -12,7 +12,10 @@ Pkeys Userspace (PKU) is a feature which can be found on:
		* Intel server CPUs, Skylake and later
		* Intel client CPUs, Tiger Lake (11th Gen Core) and later
		* Future AMD CPUs
		* arm64 CPUs implementing the Permission Overlay Extension (FEAT_S1POE)

		x86_64
		======
		Pkeys work by dedicating 4 previously Reserved bits in each page table entry to
		a "protection key", giving 16 possible keys.

		@@ -28,6 +31,22 @@ register. The feature is only available in 64-bit mode, even though there is
		theoretically space in the PAE PTEs. These permissions are enforced on data
		access only and have no effect on instruction fetches.

		arm64
		=====

		Pkeys use 3 bits in each page table entry, to encode a "protection key index",
		giving 8 possible keys.

		Protections for each key are defined with a per-CPU user-writable system
		register (POR_EL0). This is a 64-bit register encoding read, write and execute
		overlay permissions for each protection key index.

		Being a CPU register, POR_EL0 is inherently thread-local, potentially giving
		each thread a different set of protections from every other thread.

		Unlike x86_64, the protection key permissions also apply to instruction
		fetches.

		Syscalls
		========

		@@ -38,11 +57,10 @@ There are 3 system calls which directly interact with pkeys::
		int pkey_mprotect(unsigned long start, size_t len,
		unsigned long prot, int pkey);

		Before a pkey can be used, it must first be allocated with
		pkey_alloc(). An application calls the WRPKRU instruction
		directly in order to change access permissions to memory covered
		with a key. In this example WRPKRU is wrapped by a C function
		called pkey_set().
		Before a pkey can be used, it must first be allocated with pkey_alloc(). An
		application writes to the architecture specific CPU register directly in order
		to change access permissions to memory covered with a key. In this example
		this is wrapped by a C function called pkey_set().
		::

		int real_prot = PROT_READ\|PROT_WRITE;
		@@ -64,9 +82,9 @@ is no longer in use::
		munmap(ptr, PAGE_SIZE);
		pkey_free(pkey);

		.. note:: pkey_set() is a wrapper for the RDPKRU and WRPKRU instructions.
		An example implementation can be found in
		tools/testing/selftests/x86/protection_keys.c.
		.. note:: pkey_set() is a wrapper around writing to the CPU register.
		Example implementations can be found in
		tools/testing/selftests/mm/pkey-{arm64,powerpc,x86}.h

		Behavior
		========
		@@ -96,3 +114,7 @@ with a read()::
		The kernel will send a SIGSEGV in both cases, but si_code will be set
		to SEGV_PKERR when violating protection keys versus SEGV_ACCERR when
		the plain mprotect() permissions are violated.

		Note that kernel accesses from a kthread (such as io_uring) will use a default
		value for the protection key register and so will not be consistent with
		userspace's value of the register or mprotect().