Merge drm/drm-fixes into drm-misc-fixes

Getting fixes and updates from v7.1-rc1.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

Merge tag 'kernel-7.1-rc1.misc' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs

Pull pid_namespace updates from Christian Brauner:

- pid_namespace: make init creation more flexible

An

Merge tag 'kernel-7.1-rc1.misc' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs

Pull pid_namespace updates from Christian Brauner:

- pid_namespace: make init creation more flexible

Annotate ->child_reaper accesses with {READ,WRITE}_ONCE() to protect
the unlocked readers from cpu/compiler reordering, and enforce that
pid 1 in a pid namespace is always the first allocated pid (the
set_tid path already required this).

On top of that, allow opening pid_for_children before the pid
namespace init has been created. This lets one process create the pid
namespace and a different process create the init via setns(), which
makes clone3(set_tid) usable in all cases evenly and is particularly
useful to CRIU when restoring nested containers.

A new selftest covers both the basic create-pidns-then-init flow and
the cross-process variant, and a MAINTAINERS entry for the pid
namespace code is added.

- unrelated signal cleanup: update outdated comment for the removed
freezable_schedule()

* tag 'kernel-7.1-rc1.misc' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
signal: update outdated comment for removed freezable_schedule()
MAINTAINERS: add a pid namespace entry
selftests: Add tests for creating pidns init via setns
pid_namespace: allow opening pid_for_children before init was created
pid: check init is created first after idr alloc
pid_namespace: avoid optimization of accesses to ->child_reaper

show more ...

Merge patch series "pid_namespace: make init creation more flexible"

Pavel Tikhomirov <ptikhomirov@virtuozzo.com> says:

The first patch properly annotates accesses to ->child_reaper with
_ONCE macr

Merge patch series "pid_namespace: make init creation more flexible"

Pavel Tikhomirov <ptikhomirov@virtuozzo.com> says:

The first patch properly annotates accesses to ->child_reaper with
_ONCE macroses, to protect unlocked accesses from possible cpu/compiler
optimization problems.

The second patch makes sure that the init is always a first process in
the pid namespace, previously this was only checked for set_tid case.

The third patch allows to join pid namespace before pid namespace init
is created, that allows to create pid namespace by one process and then
create pid namespace init from another process after setns(). Please see
the detailed description in the patch commit message. It depends on the
second patch.

The forth and the final patch is a comprehansive test, that tests both
basic usecase of creating pid namespace and init separately, and a more
specific usecase which shows how we can improve clone3(set_tid)
usability after this change.

This change is generally useful as it makes clone3(set_tid) more
universal, and let's it work in all the cases evenly. Also it is highly
useful to CRIU to handle nested containers.

* patches from https://patch.msgid.link/20260318122157.280595-1-ptikhomirov@virtuozzo.com:
MAINTAINERS: add a new entry for testing pidns init creation via setns
selftests: Add tests for creating pidns init via setns
pid_namespace: allow opening pid_for_children before init was created
pid: check init is created first after idr alloc
pid_namespace: avoid optimization of accesses to ->child_reaper

Link: https://patch.msgid.link/20260318122157.280595-1-ptikhomirov@virtuozzo.com
Signed-off-by: Christian Brauner <brauner@kernel.org>

show more ...

selftests: Add tests for creating pidns init via setns

First testcase "pidns_init_via_setns" checks that a process can become
Pid 1 (init) in a new Pid namespace created via unshare() and joined via

selftests: Add tests for creating pidns init via setns

First testcase "pidns_init_via_setns" checks that a process can become
Pid 1 (init) in a new Pid namespace created via unshare() and joined via
setns().

Second testcase "pidns_init_via_setns_set_tid" checks that during this
process we can use clone3() + set_tid and set the pid in both the new
and old pid namespaces (owned by different user namespaces). This test
requires root to run to avoid complex setup for wrapper userns.

Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>

--
pidns_init_via_setns. Make pidns_init_via_setns_set_tid require root.

Link: https://patch.msgid.link/20260318122157.280595-5-ptikhomirov@virtuozzo.com
v6: Move wrapper userns creation for unprivileged case to the top of
Signed-off-by: Christian Brauner <brauner@kernel.org>

show more ...

Merge drm/drm-fixes into drm-misc-fixes

Backmerging to get updates from v6.15-rc1.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

Merge branch 'next' into for-linus

Prepare input updates for 6.15 merge window.

Merge tag 'v6.14-rc4' into next

Sync up with the mainline.

Merge tag 'v6.14-rc1' into perf-tools-next

To get the various fixes in the current master.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>

Merge drm/drm-next into drm-xe-next

Sync to fix conlicts between drm-xe-next and drm-intel-next.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>

Merge drm/drm-next into drm-misc-next

Bring rc1 to start the new release dev.

Signed-off-by: Maxime Ripard <mripard@kernel.org>

Merge drm/drm-next into drm-intel-next

Sync with v6.14-rc1.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Merge drm/drm-next into drm-intel-gt-next

We need
4ba4f1afb6a9 ("perf: Generic hotplug support for a PMU with a scope")
in order to land a i915 PMU simplification and a fix. That landed in 6.12
and

Merge drm/drm-next into drm-intel-gt-next

We need
4ba4f1afb6a9 ("perf: Generic hotplug support for a PMU with a scope")
in order to land a i915 PMU simplification and a fix. That landed in 6.12
and we are stuck at 6.9 so lets bump things forward.

Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>

show more ...

Merge tag 'kernel-6.14-rc1.pid' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs

Pull pid_max namespacing update from Christian Brauner:
"The pid_max sysctl is a global value. For a long ti

Merge tag 'kernel-6.14-rc1.pid' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs

Pull pid_max namespacing update from Christian Brauner:
"The pid_max sysctl is a global value. For a long time the default
value has been 65535 and during the pidfd dicussions Linus proposed to
bump pid_max by default. Based on this discussion systemd started
bumping pid_max to 2^22. So all new systems now run with a very high
pid_max limit with some distros having also backported that change.

The decision to bump pid_max is obviously correct. It just doesn't
make a lot of sense nowadays to enforce such a low pid number. There's
sufficient tooling to make selecting specific processes without typing
really large pid numbers available.

In any case, there are workloads that have expections about how large
pid numbers they accept. Either for historical reasons or
architectural reasons. One concreate example is the 32-bit version of
Android's bionic libc which requires pid numbers less than 65536.
There are workloads where it is run in a 32-bit container on a 64-bit
kernel. If the host has a pid_max value greater than 65535 the libc
will abort thread creation because of size assumptions of
pthread_mutex_t.

That's a fairly specific use-case however, in general specific
workloads that are moved into containers running on a host with a new
kernel and a new systemd can run into issues with large pid_max
values. Obviously making assumptions about the size of the allocated
pid is suboptimal but we have userspace that does it.

Of course, giving containers the ability to restrict the number of
processes in their respective pid namespace indepent of the global
limit through pid_max is something desirable in itself and comes in
handy in general.

Independent of motivating use-cases the existence of pid namespaces
makes this also a good semantical extension and there have been prior
proposals pushing in a similar direction. The trick here is to
minimize the risk of regressions which I think is doable. The fact
that pid namespaces are hierarchical will help us here.

What we mostly care about is that when the host sets a low pid_max
limit, say (crazy number) 100 that no descendant pid namespace can
allocate a higher pid number in its namespace. Since pid allocation is
hierarchial this can be ensured by checking each pid allocation
against the pid namespace's pid_max limit. This means if the
allocation in the descendant pid namespace succeeds, the ancestor pid
namespace can reject it. If the ancestor pid namespace has a higher
limit than the descendant pid namespace the descendant pid namespace
will reject the pid allocation. The ancestor pid namespace will
obviously not care about this.

All in all this means pid_max continues to enforce a system wide limit
on the number of processes but allows pid namespaces sufficient leeway
in handling workloads with assumptions about pid values and allows
containers to restrict the number of processes in a pid namespace
through the pid_max interface"

* tag 'kernel-6.14-rc1.pid' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
tests/pid_namespace: add pid_max tests
pid: allow pid_max to be set per pid namespace

show more ...

Merge patch series "pid_namespace: namespacify sysctl kernel.pid_max"

Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com> says:

The pid_max sysctl is a global value. For a long time the def

Merge patch series "pid_namespace: namespacify sysctl kernel.pid_max"

Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com> says:

The pid_max sysctl is a global value. For a long time the default value
has been 65535 and during the pidfd dicussions Linus proposed to bump
pid_max by default (cf. [1]). Based on this discussion systemd started
bumping pid_max to 2^22. So all new systems now run with a very high
pid_max limit with some distros having also backported that change.
The decision to bump pid_max is obviously correct. It just doesn't make
a lot of sense nowadays to enforce such a low pid number. There's
sufficient tooling to make selecting specific processes without typing
really large pid numbers available.

In any case, there are workloads that have expections about how large
pid numbers they accept. Either for historical reasons or architectural
reasons. One concreate example is the 32-bit version of Android's bionic
libc which requires pid numbers less than 65536. There are workloads
where it is run in a 32-bit container on a 64-bit kernel. If the host
has a pid_max value greater than 65535 the libc will abort thread
creation because of size assumptions of pthread_mutex_t.

That's a fairly specific use-case however, in general specific workloads
that are moved into containers running on a host with a new kernel and a
new systemd can run into issues with large pid_max values. Obviously
making assumptions about the size of the allocated pid is suboptimal but
we have userspace that does it.

Of course, giving containers the ability to restrict the number of
processes in their respective pid namespace indepent of the global limit
through pid_max is something desirable in itself and comes in handy in
general.

Independent of motivating use-cases the existence of pid namespaces
makes this also a good semantical extension and there have been prior
proposals pushing in a similar direction.
The trick here is to minimize the risk of regressions which I think is
doable. The fact that pid namespaces are hierarchical will help us here.

What we mostly care about is that when the host sets a low pid_max
limit, say (crazy number) 100 that no descendant pid namespace can
allocate a higher pid number in its namespace. Since pid allocation is
hierarchial this can be ensured by checking each pid allocation against
the pid namespace's pid_max limit. This means if the allocation in the
descendant pid namespace succeeds, the ancestor pid namespace can reject
it. If the ancestor pid namespace has a higher limit than the descendant
pid namespace the descendant pid namespace will reject the pid
allocation. The ancestor pid namespace will obviously not care about
this.
All in all this means pid_max continues to enforce a system wide limit
on the number of processes but allows pid namespaces sufficient leeway
in handling workloads with assumptions about pid values and allows
containers to restrict the number of processes in a pid namespace
through the pid_max interface.

* patches from https://lore.kernel.org/r/20241122132459.135120-1-aleksandr.mikhalitsyn@canonical.com:
tests/pid_namespace: add pid_max tests
pid: allow pid_max to be set per pid namespace

Link: https://lore.kernel.org/r/20241122132459.135120-1-aleksandr.mikhalitsyn@canonical.com
Signed-off-by: Christian Brauner <brauner@kernel.org>

show more ...

tests/pid_namespace: add pid_max tests

Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Link: https://lore.kernel.org/r/20241122132459.135120-3-aleksandr.mikhalitsyn@canoni

tests/pid_namespace: add pid_max tests

Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Link: https://lore.kernel.org/r/20241122132459.135120-3-aleksandr.mikhalitsyn@canonical.com
Signed-off-by: Christian Brauner <brauner@kernel.org>

show more ...

Merge branch 'master' into for-next

Sync with Linus' branch in order to be able to apply fixups
of more recent patches.

Merge branch 'next' into for-linus

Prepare input updates for 5.9 merge window.

Merge branch 'elan-i2c' into next

Bring in update to Elan touchpad driver to support newer touchpads with
higher resolution.

Merge branches 'for-5.7/upstream-fixes', 'for-5.8/apple', 'for-5.8/asus', 'for-5.8/core', 'for-5.8/intel-ish', 'for-5.8/logitech', 'for-5.8/mcp2221' and 'for-5.8/multitouch' into for-linus

Merge branch 'for-5.8' into for-linus

Merge branch 'timers/drivers/timer-ti' into timers/drivers/next

Merge branch 'kvm-amd-fixes' into HEAD

Merge branch 'for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into core/rcu

Pull RCU updates from Paul McKenney:

1. Miscellaneous fixes.
2. kfree_rcu() updates.

Merge branch 'for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into core/rcu

Pull RCU updates from Paul McKenney:

1. Miscellaneous fixes.
2. kfree_rcu() updates.
3. Remove scheduler locking restriction
4. RCU-tasks update, including addition of RCU Tasks Trace for
BPF use and RCU Tasks Rude. (This branch is on top of #3 due
to overlap of changed code.)
5. RCU CPU stall warning updates.
6. Torture-test updates.

show more ...

Merge tag 'efi-next' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into efi/core

Pull EFI changes for v5.8 from Ard Biesheuvel:

"- preliminary changes for RISC-V
- add support for setti

Merge tag 'efi-next' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into efi/core

Pull EFI changes for v5.8 from Ard Biesheuvel:

"- preliminary changes for RISC-V
- add support for setting the resolution on the EFI framebuffer
- simplify kernel image loading for arm64
- Move .bss into .data via the linker script instead of relying on symbol
annotations.
- Get rid of __pure getters to access global variables
- Clean up the config table matching arrays"

Signed-off-by: Ingo Molnar <mingo@kernel.org>

show more ...

Merge branch 'topic/nhlt' into for-next

Merge NHLT init cleanup.

Signed-off-by: Takashi Iwai <tiwai@suse.de>