linux.git/kernel/cgroup/cpuset.c, branch v7.2

cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed

2026-07-06T22:05:02+00:00

Creating a child cpuset where cpuset.mems is never set leads to a div/0
when a VMA mempolicy with MPOL_F_RELATIVE_NODES rebinds in response to a
CPU hotplug event.

Reproduction steps:
 1) Create a cgroup w/ cpuset controls (do not set cpuset.mems)
 2) Move the task into the child cpuset
 3) Create a VMA mempolicy for that task with MPOL_F_RELATIVE_NODES
 4) unplug and hotplug a cpu
      echo 0 > /sys/devices/system/cpu/cpu1/online
      echo 1 > /sys/devices/system/cpu/cpu1/online
 5) mempolicy rebind does a div/0 in mpol_relative_nodemask on the
    call to __nodes_fold()

The cpuset code passes (cs->mems_allowed) which is not guaranteed to have
nodes to the rebind routine.  Use cs->effective_mems instead, which is
guaranteed to have a non-empty nodemask once we reach that code path.

Link: https://lore.kernel.org/all/CA+0ovCiEz6SP_sn3kN4Tb+_oC=eHMXy_Ffj=usV3wREdQrUtww@mail.gmail.com/
Fixes: ae1c802382f7 ("cpuset: apply cs->effective_{cpus,mems}")
Closes: https://lore.kernel.org/linux-mm/CA+0ovCgxbZkXa+OU8w3s84R3KNPNxxRfmsNR-udh+afQBbGNmw@mail.gmail.com/
Suggested-by: Gregory Price 
Suggested-by: Waiman Long 
Acked-by: Waiman Long 
Signed-off-by: Farhad Alemi 
Cc: Andrew Morton 
Cc: Alistair Popple 
Cc: Byungchul Park 
Cc: Gregory Price 
Cc: "Huang, Ying" 
Cc: Joshua Hahn 
Cc: Matthew Brost 
Cc: Rakie Kim 
Cc: Rasmus Villemoes 
Cc: Zi Yan 
Cc: Tejun Heo 
Cc: Ridong Chen 
Cc: Johannes Weiner 
Cc: "Michal Koutný" 
Cc: 
[ david: add a comment, slightly rephrase description ]
Signed-off-by: David Hildenbrand (Arm) 
Signed-off-by: Tejun Heo

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

2026-06-17T11:03:56+00:00

Pull cgroup updates from Tejun Heo:

 - Last cycle deferred css teardown on cgroup removal until the cgroup
   depopulated, so a css is not taken offline while tasks can still
   reference it. Disabling a controller through cgroup.subtree_control
   still had the same problem. This reworks the deferral from per-cgroup
   to per-css so that path is covered too.

 - New RDMA controller monitoring files: rdma.peak for per-device peak
   usage and rdma.events / rdma.events.local for resource-limit
   exhaustion. The max-limit parser was rewritten, fixing two input
   parsing bugs.

 - cpuset: fix a sched-domain leak on the domain-rebuild failure path
   and skip a redundant hardwall ancestor scan on v2.

 - Misc: pair the remaining lockless cgroup.max.* reads with WRITE_ONCE,
   assorted selftest robustness fixes, and doc path corrections.

* tag 'cgroup-for-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: (22 commits)
  cgroup: Migrate tasks to the root css when a controller is rebound
  docs: cgroup: Fix stale source file paths
  cgroup/cpuset: Free sched domains on rebuild guard failure
  cgroup: pair max limit READ_ONCE() with WRITE_ONCE()
  selftests/cgroup: enable memory controller in hugetlb memcg test
  cgroup/rdma: Drop unnecessary READ_ONCE() on event counters
  cgroup: Defer kill_css_finish() in cgroup_apply_control_disable()
  cgroup: Add per-subsys-css kill_css_finish deferral
  cgroup: Move populated counters to cgroup_subsys_state
  cgroup: Annotate unlocked nr_populated_* accesses with READ_ONCE/WRITE_ONCE
  cgroup: Inline cgroup_has_tasks() in cgroup.h
  cgroup/rdma: document rdma.peak, rdma.events and rdma.events.local
  cgroup/rdma: add rdma.events.local for per-cgroup allocation failure attribution
  cgroup/rdma: add rdma.events to track resource limit exhaustion
  cgroup/rdma: add rdma.peak for per-device peak usage tracking
  selftests/cgroup: check malloc return value in alloc_anon functions
  cgroup/cpuset: Skip hardwall ancestor scan in cpuset v2 in cpuset_current_node_allowed()
  selftests/cgroup: fix misleading debug message in test_cgfreezer_time_child
  selftests/cgroup: fix child process escaping to parent cleanup in test_cpucg_nice
  selftests/cgroup: Add NULL check after malloc in cgroup_util.c
  ...

cgroup/cpuset: Free sched domains on rebuild guard failure

2026-05-29T18:23:18+00:00

generate_sched_domains() returns sched-domain masks and optional
attributes that are normally handed to partition_sched_domains(), which
takes ownership of them.

rebuild_sched_domains_locked() has a WARN guard after
generate_sched_domains() and before partition_sched_domains() to avoid
passing offline CPUs into the scheduler domain rebuild path. If that
guard fires, the function currently returns directly without freeing
the generated doms and attr.

Free the generated sched-domain masks and attributes before returning
from the guard failure path.

Signed-off-by: Guopeng Zhang 
Reviewed-by: Waiman Long 
Signed-off-by: Tejun Heo

cgroup/cpuset: Use effective_xcpus in partcmd_update add/del mask calculation

2026-05-27T18:58:59+00:00

When sibling CPU exclusion occurs, a partition's user_xcpus may contain
CPUs that were never actually granted to it. These CPUs are present in
user_xcpus(cs) but not in cs->effective_xcpus.

The partcmd_update path in update_parent_effective_cpumask() uses
user_xcpus(cs) (via the local variable xcpus) to compute the addmask
(CPUs to return to parent) and delmask (CPUs to request from parent).
This is incorrect:

 1) When newmask removes a CPU that was previously excluded by a
    sibling, addmask incorrectly includes that CPU and tries to return
    it to the parent even though the partition never actually owned it,
    causing CPU overlap with sibling partitions and triggering warnings
    in generate_sched_domains().

 2) When newmask adds a previously excluded CPU that is now available,
    delmask fails to request it from the parent because user_xcpus(cs)
    already includes it.

Fix this by using cs->effective_xcpus instead of user_xcpus(cs) in all
partcmd_update paths that calculate addmask or delmask, including the
PERR_NOCPUS error handling paths.

Reproducers:

  Example 1 - Removing a sibling-excluded CPU incorrectly returns it:

    # cd /sys/fs/cgroup
    # echo "0-1" > a1/cpuset.cpus
    # echo "root" > a1/cpuset.cpus.partition
    # echo "0-2" > b1/cpuset.cpus
    # echo "root" > b1/cpuset.cpus.partition
    # echo "2" > b1/cpuset.cpus
    # cat cpuset.cpus.effective
    # Actual: 0-1,3    Expected: 3

  Example 2 - Expanding to a previously excluded CPU fails to request it:

    # cd /sys/fs/cgroup
    # echo "0-1" > a1/cpuset.cpus
    # echo "root" > a1/cpuset.cpus.partition
    # echo "0-2" > b1/cpuset.cpus
    # echo "root" > b1/cpuset.cpus.partition
    # echo "member" > a1/cpuset.cpus.partition
    # echo "1-2" > b1/cpuset.cpus
    # cat cpuset.cpus.effective
    # Actual: 0-1,3    Expected: 0,3

Fixes: 2a3602030d80 ("cgroup/cpuset: Don't invalidate sibling partitions on cpuset.cpus conflict")
Cc: stable@vger.kernel.org # v7.0+
Suggested-by: Zhang Guopeng 
Signed-off-by: Sun Shaojie 
Reviewed-by: Waiman Long 
Signed-off-by: Tejun Heo

cgroup: Inline cgroup_has_tasks() in cgroup.h

2026-05-15T17:24:12+00:00

cpuset reads cs->css.cgroup->nr_populated_csets directly in two places to
test whether a cgroup has tasks. cgroup.c already has a matching helper,
cgroup_has_tasks(). Move it to cgroup.h as static inline and use that
instead. This is to prepare for relocation of cgroup->nr_populated_csets. No
semantic change.

Signed-off-by: Tejun Heo

cgroup/cpuset: Return only actually allocated CPUs during partition invalidation

2026-05-13T18:54:53+00:00

In update_parent_effective_cpumask() with partcmd_invalidate, the CPUs
to return to the parent are computed as:

    adding = cpumask_and(tmp->addmask, xcpus, parent->effective_xcpus);

where xcpus = user_xcpus(cs) which returns cs->exclusive_cpus (if set)
or cs->cpus_allowed. When exclusive_cpus is not set, user_xcpus(cs) can
contain CPUs that were never actually granted to the partition due to
sibling exclusion in compute_excpus(). Consequently, the invalidation
may return CPUs to the parent that remain in use by sibling partitions,
causing overlapping effective_cpus and triggering the
WARN_ON_ONCE(1) in generate_sched_domains().

Use cs->effective_xcpus instead, which reflects the CPUs actually
granted to this partition.

Reproducer (on a 4-CPU machine):

    cd /sys/fs/cgroup
    mkdir a1 b1

    # a1 becomes partition root with CPUs 0-1
    echo "0-1" > a1/cpuset.cpus
    echo "root" > a1/cpuset.cpus.partition

    # b1 becomes partition root with CPUs 1-2, but sibling exclusion
    # reduces its effective_xcpus to CPU 2 only
    echo "1-2" > b1/cpuset.cpus
    echo "root" > b1/cpuset.cpus.partition

    # b1 changes cpus_allowed to 0-1 -> partition invalidation
    echo "0-1" > b1/cpuset.cpus

    # Expected: CPUs 2-3  (only CPU 2 returned from b1)
    # Actual:   CPUs 1-3  (CPU 0-1 returned, overlapping with a1)
    cat cpuset.cpus.effective

dmesg will also show a WARNING from generate_sched_domains() reporting
overlapping partition root effective_cpus.

Fixes: 2a3602030d80 ("cgroup/cpuset: Don't invalidate sibling partitions on cpuset.cpus conflict")
Cc: stable@vger.kernel.org # v7.0+
Signed-off-by: sunshaojie 
Tested-by: Chen Ridong 
Reviewed-by: Chen Ridong 
Reviewed-by: Waiman Long 
Signed-off-by: Tejun Heo

cgroup/cpuset: Reserve DL bandwidth only for root-domain moves

2026-05-11T20:27:14+00:00

cpuset_can_attach() currently adds the bandwidth of all migrating
SCHED_DEADLINE tasks to sum_migrate_dl_bw. If the source and destination
cpuset effective CPU masks do not overlap, the whole sum is then
reserved in the destination root domain.

set_cpus_allowed_dl(), however, subtracts bandwidth from the source
root domain only when the affinity change really moves the task between
root domains. A DL task can move between cpusets that are still in the
same root domain, so including that task in sum_migrate_dl_bw can reserve
destination bandwidth without a matching source-side subtraction.

Share the root-domain move test with set_cpus_allowed_dl(). Keep
nr_migrate_dl_tasks counting all migrating deadline tasks for cpuset DL
task accounting, but add to sum_migrate_dl_bw only for tasks that need a
root-domain bandwidth move. Keep using the destination cpuset effective
CPU mask and leave the broader can_attach()/attach() transaction model
unchanged.

Fixes: 2ef269ef1ac0 ("cgroup/cpuset: Free DL BW in case can_attach() fails")
Cc: stable@vger.kernel.org # v6.10+
Signed-off-by: Guopeng Zhang 
Reviewed-by: Waiman Long 
Acked-by: Juri Lelli 
Tested-by: Juri Lelli 
Signed-off-by: Tejun Heo

cgroup/cpuset: Skip hardwall ancestor scan in cpuset v2 in cpuset_current_node_allowed()

2026-05-11T08:53:30+00:00

Cgroup v2 doesn't have the concept of memory hardwall, only top_cpuset
has CS_MEM_EXCLUSIVE/CS_MEM_HARDWALL flags, nearest_hardwall_ancestor
always returns top_cpuset with all nodes set, so no need to acquire
callback_lock and scan up cpuset.

Suggested-by: Michal Koutný 
Signed-off-by: Chen Wandun 
Signed-off-by: Tejun Heo

cgroup/cpuset: Reset DL migration state on can_attach() failure

2026-05-11T08:14:49+00:00

cpuset_can_attach() accumulates temporary SCHED_DEADLINE migration
state in the destination cpuset while walking the taskset.

If a later task_can_attach() or security_task_setscheduler() check
fails, cgroup_migrate_execute() treats cpuset as the failing subsystem
and does not call cpuset_cancel_attach() for it. The partially
accumulated state is then left behind and can be consumed by a later
attach, corrupting cpuset DL task accounting and pending DL bandwidth
accounting.

Reset the pending DL migration state from the common error exit when
ret is non-zero. Successful can_attach() keeps the state for
cpuset_attach() or cpuset_cancel_attach().

Fixes: 2ef269ef1ac0 ("cgroup/cpuset: Free DL BW in case can_attach() fails")
Cc: stable@vger.kernel.org # v6.10+
Signed-off-by: Guopeng Zhang 
Signed-off-by: Tejun Heo 
Reviewed-by: Chen Ridong 
Reviewed-by: Waiman Long

cgroup/cpuset: move PF_EXITING check before __GFP_HARDWALL in cpuset_current_node_allowed()

2026-05-07T21:57:31+00:00

Since prepare_alloc_pages() unconditionally adds __GFP_HARDWALL for the
fast path when cpusets are enabled, the __GFP_HARDWALL check in
cpuset_current_node_allowed() causes the PF_EXITING escape path to be
skipped on the first allocation attempt.  This makes it unreachable in
the common case, so dying tasks can get stuck in direct reclaim or even
trigger OOM while trying to exit, despite being allowed to allocate from
any node.

Move the PF_EXITING check before __GFP_HARDWALL so that dying tasks
can allocate memory from any node to exit quickly, even when cpusets
are enabled.

Also update the function comment to reflect the actual behavior of
prepare_alloc_pages() and the corrected check ordering.

Signed-off-by: Chen Wandun 
Acked-by: Michal Koutný 
Acked-by: Waiman Long 
Signed-off-by: Tejun Heo