Re: [PATCH] cgroup/cpuset: prevent overlapping local and remote partition creation

[Hui Peng]

On Sun, Sep 20, 2026 at 09:22:09AM +0800, Ridong Chen wrote:
> Could you please first describe what the issue is and how it can be triggered?
> Or is there any reproducer?

Hi Ridong,

Thanks for taking a look. Below is a detailed description of both
scenarios, how each is triggered in the current code, the dmesg
WARNINGs produced on 7.3.0-rc3, and the minimized shell reproducers.

------------------------------------------------------------------------
Scenario 1: Enabling a remote partition underneath an ancestor local
            partition root (remote_partition_enable)
------------------------------------------------------------------------

How it happens:
1. Suppose top-level cgroup "A" is a valid local partition root owning
   CPU 1 (cpuset.cpus = 1, cpuset.cpus.exclusive = 1,
   cpuset.cpus.partition = root). Enabling "A" calls
   partition_xcpus_add(..., &top_cpuset, {1}), which adds CPU 1 to
   subpartitions_cpus.
2. Child "A/B" is a normal non-partition member (cpuset.cpus.partition =
   member) with cpuset.cpus = 1 and cpuset.cpus.exclusive = 1.
3. Grandchild "A/B/D" has cpuset.cpus = 1, cpuset.cpus.exclusive = 1.
   When "root" is written to "A/B/D/cpuset.cpus.partition",
   update_prstate() checks is_partition_valid(parent) on A/B (which is
   false because A/B is PRS_MEMBER) and therefore calls
   remote_partition_enable(D, PRS_ROOT, &tmpmask).
4. In remote_partition_enable(), compute_excpus(D, tmp->new_cpus) walks
   up D -> B -> A and computes tmp->new_cpus = {1}. Because ancestor "A"
   is already a valid local partition root, CPU 1 is already present in
   subpartitions_cpus.
5. remote_partition_enable() hits:
     WARN_ON_ONCE(cpumask_intersects(tmp->new_cpus, subpartitions_cpus));
   at kernel/cgroup/cpuset.c:1594 and continues without returning an
   error, enabling "A/B/D" as a valid remote partition on CPU 1 while
   ancestor "A" is simultaneously a valid local partition on CPU 1,
   which then also triggers a second WARNING in
   rebuild_sched_domains_locked() (kernel/cgroup/cpuset.c:906).

Minimized reproducer (Scenario 1):
  #!/bin/sh
  mkdir -p /tmp/cg1
  mount -t cgroup2 none /tmp/cg1
  echo "+cpuset" > /tmp/cg1/cgroup.subtree_control

  mkdir /tmp/cg1/A
  echo 1 > /tmp/cg1/A/cpuset.cpus
  echo 1 > /tmp/cg1/A/cpuset.cpus.exclusive
  echo root > /tmp/cg1/A/cpuset.cpus.partition
  echo "+cpuset" > /tmp/cg1/A/cgroup.subtree_control

  mkdir /tmp/cg1/A/B
  echo 1 > /tmp/cg1/A/B/cpuset.cpus
  echo 1 > /tmp/cg1/A/B/cpuset.cpus.exclusive
  echo "+cpuset" > /tmp/cg1/A/B/cgroup.subtree_control

  mkdir /tmp/cg1/A/B/D
  echo 1 > /tmp/cg1/A/B/D/cpuset.cpus
  echo 1 > /tmp/cg1/A/B/D/cpuset.cpus.exclusive
  echo root > /tmp/cg1/A/B/D/cpuset.cpus.partition

dmesg output on 7.3.0-rc3:
  WARNING: kernel/cgroup/cpuset.c:1594 at update_prstate+0xbef/0xd70, CPU#2
  Call Trace:
   cpuset_partition_write+0x112/0x140
  WARNING: kernel/cgroup/cpuset.c:906 at rebuild_sched_domains_locked+0x4f2/0x710, CPU#2
  Call Trace:
   cpuset_partition_write+0x112/0x140

------------------------------------------------------------------------
Scenario 2: Invalid top-level local partition transitioning to valid
            over an active remote child partition (validate_partition)
------------------------------------------------------------------------

How it happens:
1. Suppose top-level cgroup "A" is configured as a partition root
   (echo root > A/cpuset.cpus.partition) and given all online CPUs
   (e.g., echo 0-3 > A/cpuset.cpus.exclusive on a 4-CPU system), which
   transitions "A" to PRS_INVALID_ROOT ("root invalid (Parent unable to
   distribute cpu downstream)").
2. Because "A" is invalid (!is_partition_valid(A)), creating child "A/R"
   with cpuset.cpus = 1, cpuset.cpus.exclusive = 1, and
   cpuset.cpus.partition = root succeeds via remote_partition_enable(),
   making "A/R" a valid remote partition on CPU 1 (adding CPU 1 to
   subpartitions_cpus and removing CPU 1 from top_cpuset.effective_cpus).
3. Next, shrinking "A/cpuset.cpus.exclusive" from "0-3" to "1" calls
   update_exclusive_cpumask() -> partition_cpus_change(A, trialcs, &tmp)
   -> validate_partition(A, trialcs).
4. Unlike update_prstate() (which checks (parent == &top_cpuset) &&
   cpumask_intersects(..., subpartitions_cpus) and returns PERR_REMOTE),
   validate_partition() omits the subpartitions_cpus check and returns
   PERR_NONE (0).
5. partition_cpus_change() then calls update_parent_effective_cpumask(A,
   partcmd_update, trialcs->effective_xcpus, &tmp) to activate "A" on
   CPU 1, which is already removed from top_cpuset.effective_cpus by
   "A/R", triggering WARN_ON_ONCE(!cpumask_subset(tmp->new_cpus,
   parent->effective_cpus)) at kernel/cgroup/cpuset.c:1943 and
   WARN_ON_ONCE(old_prs < 0) in partition_xcpus_del() at
   kernel/cgroup/cpuset.c:1342.

Minimized reproducer (Scenario 2, on a 4-CPU VM):
  #!/bin/sh
  mkdir -p /tmp/cg2
  mount -t cgroup2 none /tmp/cg2
  echo "+cpuset" > /tmp/cg2/cgroup.subtree_control

  mkdir /tmp/cg2/A
  echo root > /tmp/cg2/A/cpuset.cpus.partition
  echo 0-3 > /tmp/cg2/A/cpuset.cpus.exclusive
  echo "+cpuset" > /tmp/cg2/A/cgroup.subtree_control

  mkdir /tmp/cg2/A/R
  echo 1 > /tmp/cg2/A/R/cpuset.cpus
  echo 1 > /tmp/cg2/A/R/cpuset.cpus.exclusive
  echo root > /tmp/cg2/A/R/cpuset.cpus.partition

  # Shrink A's exclusive_cpus to 1
  echo 1 > /tmp/cg2/A/cpuset.cpus.exclusive

dmesg output on 7.3.0-rc3:
  WARNING: kernel/cgroup/cpuset.c:1943 at update_parent_effective_cpumask+0x189b/0x1fd0
  Call Trace:
   cpuset_write_resmask+0xcf2/0x1690
  WARNING: kernel/cgroup/cpuset.c:1342 at partition_xcpus_del+0x15b/0x1b0
  Call Trace:
   update_parent_effective_cpumask+0x118c/0x1fd0
   cpuset_write_resmask+0xcf2/0x1690

Also, in v2 of the patch, I will refine the check in validate_partition()
to exclude cs's own existing effective_xcpus when cs is already a valid
local partition (!is_partition_valid(cs)), and split the two scenarios
into separate patches with these reproducers in the commit messages if
you prefer.

Best regards,
Hui Peng