Re: [PATCH v2] cgroup/cpuset: Invalidate remote partition on housekeeping conflict
From: Waiman Long
Date: Mon Sep 28 2026 - 19:56:54 EST
On 9/28/26 2:44 PM, Tejun Heo wrote:
Hello, Guopeng.
The following is a Claude-generated review.
On Sun, Sep 27, 2026 at 05:57:21PM +0800, Guopeng Zhang wrote:
+ bool updating = is_remote_partition(cs);cs->remote_partition can be stale when remote_partition_enable() is
+
+ if (!capable(CAP_SYS_ADMIN))
+ return PERR_ACCESS;
+
+ if (!updating &&
+ (!cpumask_intersects(excpus, cpu_active_mask) ||
+ cpumask_subset(top_cpuset.effective_cpus, addcpus)))
+ return PERR_INVCPUS;
called. If a root <-> isolated switch of a valid remote partition fails
in update_prstate(), the partition is made invalid without
remote_partition_disable(), so the flag stays set and its CPUs stay in
subpartitions_cpus. A later enable then skips the PERR_INVCPUS checks.
With isolcpus=domain,4:
1. A is a member with cpuset.cpus 2-6 and cpuset.cpus.exclusive 2-4. B
has cpuset.cpus 2-4 and no cpuset.cpus.exclusive.
2. "isolated" to B's cpuset.cpus.partition. B becomes a valid remote
partition with effective_xcpus 2-4.
3. "root" to B's cpuset.cpus.partition fails with PERR_HKEEPING.
effective_xcpus is cleared but remote_partition stays set.
4. 5-6 to A's cpuset.cpus.exclusive. B's excpus becomes empty, which
matches the cleared effective_xcpus, so update_cpumasks_hier() skips
B.
5. "isolated" to B's cpuset.cpus.partition. This used to fail with
PERR_INVCPUS. Now B becomes a valid isolated partition with empty
effective_xcpus and the WARN_ON_ONCE() at the end of update_prstate()
triggers.
This is from reading the code, not reproduced. Maybe have the callers
pass whether it's an enable or an update instead of deriving it from
cs->remote_partition?
The stale flag itself is a separate, pre-existing bug. Switching B back
to member after step 3 trips the WARN_ON_ONCE(old_prs < 0) in
partition_xcpus_del().
You are right. It is a bug that has to be fixed. I have posted a cpuset patch to fix that partition state switch bug.
Cheers,
Longman
Thanks.
--
tejun