Re: [PATCH v2] cgroup/cpuset: Invalidate remote partition on housekeeping conflict

[Tejun Heo <tj@kernel.org>]

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);
> +
> +	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;

cs->remote_partition can be stale when remote_partition_enable() is
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().

Thanks.

--
tejun