Changes in .gitignore

0fc8f6200d2313278fbf4539bbab74677c685531 - Merge drm/drm-fixes into drm-misc-fixes

Mon, 27 Apr 2026 10:26:49 +0200

Merge drm/drm-fixes into drm-misc-fixesGetting fixes and updates from v7.1-rc1.Signed-off-by: Thomas Zimmermann List of files: /linux/tools/testing/selftests/pid_namespace/.gitignore

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

Wed, 15 Apr 2026 05:28:40 +0200

Merge tag 'kernel-7.1-rc1.misc' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfsPull 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 List of files: /linux/tools/testing/selftests/pid_namespace/.gitignore

68b953730e94c0b3417573b7288d78995a48be4b - Merge patch series "pid_namespace: make init creation more flexible"

Fri, 20 Mar 2026 14:44:31 +0100

Merge patch series "pid_namespace: make init creation more flexible"Pavel Tikhomirov says:The first patch properly annotates accesses to ->child_reaper with_ONCE macroses, to protect unlocked accesses from possible cpu/compileroptimization problems.The second patch makes sure that the init is always a first process inthe pid namespace, previously this was only checked for set_tid case.The third patch allows to join pid namespace before pid namespace initis created, that allows to create pid namespace by one process and thencreate pid namespace init from another process after setns(). Please seethe detailed description in the patch commit message. It depends on thesecond patch.The forth and the final patch is a comprehansive test, that tests bothbasic usecase of creating pid namespace and init separately, and a morespecific 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) moreuniversal, and let's it work in all the cases evenly. Also it is highlyuseful 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_reaperLink: https://patch.msgid.link/20260318122157.280595-1-ptikhomirov@virtuozzo.comSigned-off-by: Christian Brauner List of files: /linux/tools/testing/selftests/pid_namespace/.gitignore

7c5219e1a60686c04fe12536d96721d538635130 - selftests: Add tests for creating pidns init via setns

Wed, 18 Mar 2026 13:21:52 +0100

selftests: Add tests for creating pidns init via setnsFirst testcase "pidns_init_via_setns" checks that a process can becomePid 1 (init) in a new Pid namespace created via unshare() and joined viasetns().Second testcase "pidns_init_via_setns_set_tid" checks that during thisprocess we can use clone3() + set_tid and set the pid in both the newand old pid namespaces (owned by different user namespaces). This testrequires root to run to avoid complex setup for wrapper userns.Signed-off-by: Pavel Tikhomirov --pidns_init_via_setns. Make pidns_init_via_setns_set_tid require root.Link: https://patch.msgid.link/20260318122157.280595-5-ptikhomirov@virtuozzo.comv6: Move wrapper userns creation for unprivileged case to the top ofSigned-off-by: Christian Brauner List of files: /linux/tools/testing/selftests/pid_namespace/.gitignore

1260ed77798502de9c98020040d2995008de10cc - Merge drm/drm-fixes into drm-misc-fixes

Tue, 08 Apr 2025 10:15:47 +0200

Merge drm/drm-fixes into drm-misc-fixesBackmerging to get updates from v6.15-rc1.Signed-off-by: Thomas Zimmermann List of files: /linux/tools/testing/selftests/pid_namespace/.gitignore

946661e3bef8efa11ba8079d4ebafe6fc3b0aaad - Merge branch 'next' into for-linus

Sat, 05 Apr 2025 08:04:35 +0200

Merge branch 'next' into for-linusPrepare input updates for 6.15 merge window. List of files: /linux/tools/testing/selftests/pid_namespace/.gitignore

0b119045b79a672bc6d8f18641c60fc8ce1b4585 - Merge tag 'v6.14-rc4' into next

Wed, 26 Feb 2025 01:03:25 +0100

Merge tag 'v6.14-rc4' into nextSync up with the mainline. List of files: /linux/tools/testing/selftests/pid_namespace/.gitignore

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

Wed, 05 Feb 2025 23:57:18 +0100

Merge tag 'v6.14-rc1' into perf-tools-nextTo get the various fixes in the current master.Signed-off-by: Namhyung Kim List of files: /linux/tools/testing/selftests/pid_namespace/.gitignore

0410c6121529409b08e81a77ae3ee58c657e2243 - Merge drm/drm-next into drm-xe-next

Fri, 28 Feb 2025 15:54:14 +0100

Merge drm/drm-next into drm-xe-nextSync to fix conlicts between drm-xe-next and drm-intel-next.Signed-off-by: Lucas De Marchi List of files: /linux/tools/testing/selftests/pid_namespace/.gitignore

93c7dd1b39444ebd5a6a98e56a363d7a4e646775 - Merge drm/drm-next into drm-misc-next

Thu, 06 Feb 2025 13:47:32 +0100

Merge drm/drm-next into drm-misc-nextBring rc1 to start the new release dev.Signed-off-by: Maxime Ripard List of files: /linux/tools/testing/selftests/pid_namespace/.gitignore

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

Wed, 05 Feb 2025 18:12:37 +0100

Merge drm/drm-next into drm-intel-nextSync with v6.14-rc1.Signed-off-by: Jani Nikula List of files: /linux/tools/testing/selftests/pid_namespace/.gitignore

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

Wed, 05 Feb 2025 10:29:14 +0100

Merge drm/drm-next into drm-intel-gt-nextWe need4ba4f1afb6a9 ("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.12and we are stuck at 6.9 so lets bump things forward.Signed-off-by: Tvrtko Ursulin List of files: /linux/tools/testing/selftests/pid_namespace/.gitignore

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

Mon, 20 Jan 2025 19:29:11 +0100

Merge tag 'kernel-6.14-rc1.pid' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfsPull 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 List of files: /linux/tools/testing/selftests/pid_namespace/.gitignore

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

Tue, 26 Nov 2024 11:10:15 +0100

Merge patch series "pid_namespace: namespacify sysctl kernel.pid_max"Alexander Mikhalitsyn says:The pid_max sysctl is a global value. For a long time the default valuehas been 65535 and during the pidfd dicussions Linus proposed to bumppid_max by default (cf. [1]). Based on this discussion systemd startedbumping pid_max to 2^22. So all new systems now run with a very highpid_max limit with some distros having also backported that change.The decision to bump pid_max is obviously correct. It just doesn't makea lot of sense nowadays to enforce such a low pid number. There'ssufficient tooling to make selecting specific processes without typingreally large pid numbers available.In any case, there are workloads that have expections about how largepid numbers they accept. Either for historical reasons or architecturalreasons. One concreate example is the 32-bit version of Android's bioniclibc which requires pid numbers less than 65536. There are workloadswhere it is run in a 32-bit container on a 64-bit kernel. If the hosthas a pid_max value greater than 65535 the libc will abort threadcreation because of size assumptions of pthread_mutex_t.That's a fairly specific use-case however, in general specific workloadsthat are moved into containers running on a host with a new kernel and anew systemd can run into issues with large pid_max values. Obviouslymaking assumptions about the size of the allocated pid is suboptimal butwe have userspace that does it.Of course, giving containers the ability to restrict the number ofprocesses in their respective pid namespace indepent of the global limitthrough pid_max is something desirable in itself and comes in handy ingeneral.Independent of motivating use-cases the existence of pid namespacesmakes this also a good semantical extension and there have been priorproposals pushing in a similar direction.The trick here is to minimize the risk of regressions which I think isdoable. 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_maxlimit, say (crazy number) 100 that no descendant pid namespace canallocate a higher pid number in its namespace. Since pid allocation ishierarchial this can be ensured by checking each pid allocation againstthe pid namespace's pid_max limit. This means if the allocation in thedescendant pid namespace succeeds, the ancestor pid namespace can rejectit. If the ancestor pid namespace has a higher limit than the descendantpid namespace the descendant pid namespace will reject the pidallocation. The ancestor pid namespace will obviously not care aboutthis.All in all this means pid_max continues to enforce a system wide limiton the number of processes but allows pid namespaces sufficient leewayin handling workloads with assumptions about pid values and allowscontainers to restrict the number of processes in a pid namespacethrough 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 namespaceLink: https://lore.kernel.org/r/20241122132459.135120-1-aleksandr.mikhalitsyn@canonical.comSigned-off-by: Christian Brauner List of files: /linux/tools/testing/selftests/pid_namespace/.gitignore

615ab43b838bb982dc234feff75ee9ad35447c5d - tests/pid_namespace: add pid_max tests

Fri, 22 Nov 2024 14:24:59 +0100

tests/pid_namespace: add pid_max testsSigned-off-by: Alexander Mikhalitsyn Link: https://lore.kernel.org/r/20241122132459.135120-3-aleksandr.mikhalitsyn@canonical.comSigned-off-by: Christian Brauner List of files: /linux/tools/testing/selftests/pid_namespace/.gitignore

ead5d1f4d877e92c051e1a1ade623d0d30e71619 - Merge branch 'master' into for-next

Tue, 01 Sep 2020 14:19:48 +0200

Merge branch 'master' into for-nextSync with Linus' branch in order to be able to apply fixupsof more recent patches. List of files: /linux/tools/testing/selftests/pid_namespace/.gitignore

9e8238020c5beba64e7ffafbb7ea0fb02fe68270 - Merge branch 'next' into for-linus

Sat, 08 Aug 2020 01:41:01 +0200

Merge branch 'next' into for-linusPrepare input updates for 5.9 merge window. List of files: /linux/tools/testing/selftests/pid_namespace/.gitignore

9b031c86506cef9acae45e61339fcf9deaabb793 - Merge branch 'elan-i2c' into next

Wed, 22 Jul 2020 04:02:33 +0200

Merge branch 'elan-i2c' into nextBring in update to Elan touchpad driver to support newer touchpads withhigher resolution. List of files: /linux/tools/testing/selftests/pid_namespace/.gitignore

16ba7e312045cd5d32fba0156312b4303f200787 - 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

Wed, 03 Jun 2020 22:23:52 +0200

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 List of files: /linux/tools/testing/selftests/pid_namespace/.gitignore

d053cf0d771f6547cb0537759a9af63cf402908d - Merge branch 'for-5.8' into for-linus

Mon, 01 Jun 2020 10:15:16 +0200

Merge branch 'for-5.8' into for-linus List of files: /linux/tools/testing/selftests/pid_namespace/.gitignore