linux-rng/kernel/cgroup, branch master

Merge tag 'cgroup-for-7.4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup

2026-10-29T17:35:19Z

Pull cgroup fixes from Tejun Heo: - cgroup.kill did not kill a process whose thread group leader had exited while other threads still ran, nor those threads once moved to another cgroup, letting a process survive its container being killed - A cgroup.procs write under favordynmods could migrate a newly forked process before fork linked it to its cgroup, corrupting cgroup task lists - cpuset partition fixes for nested hierarchies: invalidation, revival, shrinking and switches between root and isolated could leak isolated CPUs, skip or miscompute the housekeeping check, or leave wrong effective CPUs: - A root partition can no longer be created under an isolated parent or stay valid under one, as disabling it could leave no housekeeping CPUs - Enabling a partition failed when a grandchild held tasks, although the parent had none of its own - Separately, an allocation racing with a cpuset.mems update could drop its mempolicy nodemask and land on the wrong node, and a memoryless node in cpuset.mems triggered a spurious "movable nodes only" warning - Two no-functional-change cleanups of the effective CPU computation * tag 'cgroup-for-7.4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: (27 commits) cgroup/cpuset: Integrate compute_partition_effective_cpumask() into compute_effective_cpumask() cgroup/cpuset: Relocate compute_*effective_cpumask() and compute_effective_nodemask() cgroup/cpuset: Release invalid isolated CPUs with a shrunk root partition parent cgroup/cpuset: Release invalid isolated CPUs in compute_partition_effective_cpumask() cgroup/cpuset: Make sure compute_partition_effective_cpumask() is only called for valid partition cgroup/cpuset: Prevent recursive call of remote_cpus_update() via update_cpumasks_hier() selftests/cgroup: Check for a single range nohz_full CPUs before running test matrix cgroup/cpuset: Minor fixes to prstate_housekeeping_conflict() cgroup/cpuset: Fix incorrect effective_cpus bug in update_cpumasks_hier() cgroup/cpuset: Properly compute effective xcpus in update_parent_effective_cpumask() cgroup/cpuset: Find furthest isolated ancestor for invalidated isolated partition cgroup: don't kill migrated processes through their exiting threads cgroup/cpuset: check effective mems for a movable-only configuration cgroup/cpuset: Fix task checking when enabling a partition cgroup: serialize migrations of newly forked processes selftests/cgroup: test cgroup.kill with an exited thread group leader cgroup: fix cgroup.kill for exited thread group leader selftests/cgroup: Skip test_cpuset_prs.sh test if some required CPUs are offline selftests/cgroup: Add tests for nohz_full housekeeping check selftests/cgroup: Add tests for isolcpus housekeeping check ...

cgroup/cpuset: Integrate compute_partition_effective_cpumask() into compute_effective_cpumask()

2026-10-26T17:44:43Z

Update compute_effective_cpumask() to call compute_partition_effective_cpumask() directly if the given cpuset is a valid remote or local partition root. This simplifies the call sites where they are being involved. No functional change is expected. Suggested-by: Ridong Chen Signed-off-by: Waiman Long Acked-by: Guopeng Zhang Signed-off-by: Tejun Heo

cgroup/cpuset: Relocate compute_*effective_cpumask() and compute_effective_nodemask()

2026-10-26T17:44:40Z

Relocate compute_partition_effective_cpumask(), compute_effective_cpumask(), and compute_effective_nodemask() together so that compute_effective_cpumask() and compute_partition_effective_cpumask() can be further integrated together. There is no functional change. Signed-off-by: Waiman Long Acked-by: Guopeng Zhang Signed-off-by: Tejun Heo

cgroup/cpuset: Release invalid isolated CPUs with a shrunk root partition parent

2026-10-26T17:44:36Z

It is also reported by sashiko that there may be leakages of isolated CPUs when a root partition parent shrinks its effective_xcpus with isolated partition children. Leakage here means that isolated_cpus may contain extra CPUs that are not in any isolated partitions and not boot time isolated. Those CPUs cannot be used in any isolated partitions anymore. There are 2 different cases here. The effective_xcpus becomes empty and the isolated partition should be invalidated in this case. Alternatively some of its effective_xcpus are not in parent's effective xcpus but still have some valid effective_xcpus left. The isolated partition can remain valid. In both cases, the invalid isolated CPUs will have to be released from isolated_cpus if appropriate. Fix that by calling isolated_cpus_release() to release those isolated CPUs from isolated_cpus. New test cases are added to test_cpuset_prs.sh to test this. Fixes: 11e5f407b64a ("cgroup/cpuset: Keep track of CPUs in isolated partitions") Signed-off-by: Waiman Long Reviewed-by: Guopeng Zhang Tested-by: Guopeng Zhang Signed-off-by: Tejun Heo

cgroup/cpuset: Release invalid isolated CPUs in compute_partition_effective_cpumask()

2026-10-26T17:44:32Z

It is found by sashiko that when a child isolated partition with parent root partition is invalidated in compute_partition_effective_cpumask(), the switching of the isolated exclusive CPUs from child to parent will not be reflected in isolated_cpus leading to CPU leakage. Fix that by calling isolated_cpus_update() when that happens. Also simplify compute_partition_effective_cpumask() by doing child partition invalidation only for the special case of no more effective_cpus left in a populated parent. The other case doesn't actually warrant invalidation at this stage and subsequent iteration in update_cpumasks_hier() and update_parent_effective_cpumask() for that child should handle that. Also drop the make_partition_invalid() helper by inlining it into compute_partition_effective_cpumask() as it is the only caller. A new test case is add to test_cpuset_prs.sh to verify this. Fixes: 11e5f407b64a ("cgroup/cpuset: Keep track of CPUs in isolated partitions") Signed-off-by: Waiman Long Reviewed-by: Guopeng Zhang Tested-by: Guopeng Zhang Signed-off-by: Tejun Heo

cgroup/cpuset: Make sure compute_partition_effective_cpumask() is only called for valid partition

2026-10-26T17:44:28Z

With visual inspection to make sure that compute_partition_effective_cpumask() is only called for valid partition root, it was found that the function can be called for an invalidated partition near the end of cpuset_hotplug_update_tasks(). When partcmd is set, update_parent_effective_cpumask() is called to either invalidate a valid partition or with partcmd_update to check if an invalid partition can be switched back to valid. In both cases, cpuset_force_rebuild() should be invoked. However, compute_partition_effective_cpumask() should only be called when an invalid partition is switched back to valid. When a partition is invalidated, compute_effective_cpumask() should be called instead. Also add a WARN_ON_ONCE() in compute_partition_effective_cpumask() to ensure that a valid partition root is passed in. Fixes: 72c6303acfa1 ("cgroup/cpuset: Take isolated CPUs out of workqueue unbound cpumask") Signed-off-by: Waiman Long Acked-by: Guopeng Zhang Signed-off-by: Tejun Heo

cgroup/cpuset: Prevent recursive call of remote_cpus_update() via update_cpumasks_hier()

2026-10-26T17:44:25Z

Guopeng reports that changing the cpumask of a remote partition root may set the effective_cpus of the top_cpuset incorrectly. It is due to the following call sequence: update_cpumask() -> partition_cpus_change() -> remote_cpus_update() -> update_sibling_cpumasks() -> update_cpumasks_hier() -> remote_cpus_update() The second remote_cpus_update() call passes in the cs->effective_xcpus instead of the trialcs->effective_xcpus of the first remote_cpus_update() call. As a result, the second call can revert what has been done in the first call leading to incorrect effective_cpus of the top_cpuset as well as subpartitions_cpus. Fix that by adding a new remote_partition_updating flag into the cpuset structure to indicate that a remote partition is being updated and update_cpumasks_hier() should skip the whole subtree as update_cpumask() or update_exclusive_cpumask() which calls partition_cpus_change() will eventually calls update_cpumasks_hier() for that subtree anyway. This new flag is currently set only in remote_cpus_update() to prevent recursive call of remote_cpus_update() on the same cpuset. A test case is added to test_cpuset_prs.sh to verify this change. Reported-by: Guopeng Zhang Link: https://lore.kernel.org/lkml/20261010075947.333549-2-guopeng.zhang@linux.dev Reviewed-by: Guopeng Zhang Tested-by: Guopeng Zhang Fixes: f62a5d39368e ("cgroup/cpuset: Remove remote_partition_check() & make update_cpumasks_hier() handle remote partition") Signed-off-by: Waiman Long Signed-off-by: Tejun Heo

cgroup/cpuset: Minor fixes to prstate_housekeeping_conflict()

2026-10-26T17:44:17Z

Commit 9527ff78a413 ("cgroup/cpuset: Consider all the exclusive CPUs when doing housekeeping check") changes the way prstate_housekeeping_conflict() is being used by considering all the exclusive xcpus to be owned by the partition when doing housekeeping check. However there are two minor issues reported by sashiko with that patch: 1) In partition_cpus_change(), prstate_housekeeping_conflict() can be called with an invalid partition root. In that case, there are no isolated CPUs that are going to be returned back to the system to become housekeeping CPUs, so the calculation of the del_cpus cpumask is meaningless. 2) The checking of del_cpus in prstate_housekeeping_conflict() to see if it can contain an active housekeeping CPU that can be returned to the system ignores the fact that an active CPU not in HK_TYPE_DOMAIN_BOOT HK cpumask will not become an active housekeeping CPU when it is released by an isolated partition. Update the existing code to handle these two issues properly to make prstate_housekeeping_conflict() produce more accurate result. Fixes: 9527ff78a413 ("cgroup/cpuset: Consider all the exclusive CPUs when doing housekeeping check") Signed-off-by: Waiman Long Reviewed-by: Guopeng Zhang Signed-off-by: Tejun Heo

cgroup/cpuset: Fix incorrect effective_cpus bug in update_cpumasks_hier()

2026-10-26T17:44:14Z

With the introduction of cpuset.cpus.exclusive, the computation of effective_cpus differs depending on if a cpuset is a valid partition root or not. In update_cpumasks_hier(), effective_cpus is computed early to check if the current subtree can be skipped. Later on update_parent_effective_cpumask() may be called which can change the partition state from valid to invalid or vice versa. If the partition state changes, the previously computed effective_cpus may no longer be valid. Fix that by recomputing effective_cpus again when that happens. Also add a new test case into test_cpuset_prs.sh to verify this change. Fixes: e2ffe502ba45 ("cgroup/cpuset: Add cpuset.cpus.exclusive for v2") Signed-off-by: Waiman Long Reviewed-by: Guopeng Zhang Signed-off-by: Tejun Heo

cgroup/cpuset: Properly compute effective xcpus in update_parent_effective_cpumask()

2026-10-26T17:44:11Z

Since the introduction of cpuset.cpus.exclusive in commit e2ffe502ba45 ("cgroup/cpuset: Add cpuset.cpus.exclusive for v2"), a compute_effective_exclusive_cpumask() helper which is later renamed to compute_excpus() is added to compute the effective xcpus of a partition root. However update_parent_effective_cpumask() is not updated in all proper places to use the new helper to check if a given cpuset should remain a valid partition root. This can cause a cpuset to incorrectly remain a valid partition root even if no effective xcpus is left. Fix that problem by using compute_excpus() to compute the effective xcpus into delmask in all cases except partcmd_disable, partcmd_invalidate or partcmd_update with newmask set and use it for tasks_nocpu_error() check as well as checking its emptiness. This enables us to catch invalid partition root more accurately in update_parent_effective_cpumask(). In the case of partcmd_update with newmask set, the passed in new effective xcpus value will directly be used in the tasks_nocpu_error() check without relying on old data in the cpuset. For the partcmd_update with NULL newmask case, the cpu exclusivity test there is also relaxed to be performed only if exclusive_cpus is empty. Some test case are added to test_cpuset_prs.sh for invalidating a partition root due to its effective xcpus becoming empty as well as making sure that an invalid partition can only be revived when exclusive CPUs are available agin. Fixes: e2ffe502ba45 ("cgroup/cpuset: Add cpuset.cpus.exclusive for v2") Signed-off-by: Waiman Long Reviewed-by: Guopeng Zhang Tested-by: Guopeng Zhang Signed-off-by: Tejun Heo