Hello, Hui.
The following is a Claude-generated review.
On Thu, Sep 24, 2026 at 04:27:29AM +0000, Hui Peng wrote:
> In cpus_excl_conflict(), when a valid local partition A1 uses implicit
> exclusive CPUs (cpuset.cpus set without cpuset.cpus.exclusive, so
> sibling->exclusive_cpus is empty while sibling->effective_xcpus is
> populated), a sibling cgroup B1 can still set cpuset.cpus.exclusive on
> the same CPUs because cpus_excl_conflict() only checks
> sibling->exclusive_cpus.
update_exclusive_cpumask() runs compute_trialcs_excpus() before
validate_change(), and rm_siblings_excl_cpus() already falls back to the
sibling's effective_xcpus when its exclusive_cpus is empty:
sibling_xcpus = cpumask_empty(sibling->exclusive_cpus)
? sibling->effective_xcpus
: sibling->exclusive_cpus;
if (cpumask_intersects(excpus, sibling_xcpus)) {
cpumask_andnot(excpus, excpus, sibling_xcpus);
retval++;
}
With A1 a valid partition on 0-3, B1's write of 3-5 hits CPU 3 there and
fails with -EINVAL before cpus_excl_conflict() is reached, so the added
check doesn't change the outcome and the new test row should pass without
the kernel change. Was the write observed to succeed somewhere? That check
also predates 2a3602030d80, so the Fixes tag wouldn't hold either.
Thanks.
--
tejun
