From: Guopeng Zhang <guopeng.zhang@linux.dev>
To: Hui Peng <benquike@gmail.com>,
longman@redhat.com, ridong.chen@linux.dev, tj@kernel.org,
hannes@cmpxchg.org, mkoutny@suse.com
Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cgroup/cpuset: prevent overlapping local and remote partition creation
Date: Sun, 20 Sep 2026 14:30:23 +0800 [thread overview]
Message-ID: <25b72fce-5354-435b-9256-482c15ae7b06@linux.dev> (raw)
In-Reply-To: <20260919221727.3706964-1-benquike@gmail.com>
在 2026/9/20 06:17, Hui Peng 写道:
Hello Hui,
> Fix two partition validation bugs in kernel/cgroup/cpuset.c:
>
> 1. In remote_partition_enable(), check whether the requested effective
> xcpus intersect parent->subpartitions_cpus so a remote partition
> cannot claim CPUs already delegated to a local child partition.
> 2. In validate_partition(), verify that enabling a local partition does
> not overlap CPUs already allocated to an active remote partition.
>
> Fixes: aa7d3a56a20f ("cpuset: fix warning when disabling remote partition")
> Assisted-by: LLM
> Signed-off-by: Hui Peng <benquike@gmail.com>
> ---
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index 2538faac9aba..13fad096c494 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -713,7 +713,10 @@ static inline bool cpus_excl_conflict(struct cpuset *trial, struct cpuset *sibli
> return true;
>
> /* Exclusive_cpus cannot intersect */
> - return cpumask_intersects(trial->exclusive_cpus, sibling->exclusive_cpus);
> + return cpumask_intersects(trial->exclusive_cpus,
> + cpumask_empty(sibling->exclusive_cpus)
> + ? sibling->effective_xcpus
> + : sibling->exclusive_cpus);
> }
>
> static inline bool mems_excl_conflict(struct cpuset *cs1, struct cpuset *cs2)
> @@ -1591,8 +1594,8 @@ static int remote_partition_enable(struct cpuset *cs, int new_prs,
> * above it or remote partition root underneath it is not allowed.
> */
> compute_excpus(cs, tmp->new_cpus);
> - WARN_ON_ONCE(cpumask_intersects(tmp->new_cpus, subpartitions_cpus));
> if (!cpumask_intersects(tmp->new_cpus, cpu_active_mask) ||
> + cpumask_intersects(tmp->new_cpus, subpartitions_cpus) ||
> cpumask_subset(top_cpuset.effective_cpus, tmp->new_cpus))
> return PERR_INVCPUS;
I have been going through this part of the code repeatedly recently, and I
would like to share one thought.
Should this return PERR_NOCPUS instead?
+ if (cpumask_intersects(tmp->new_cpus, subpartitions_cpus))
+ return PERR_NOCPUS;
In the first reproducer you described in your reply to Ridong:
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
CPU 1 is active, and the requested CPU mask itself is valid. The failure
happens because CPU 1 has already been allocated to partition A, so the
top cpuset can no longer distribute it to the remote partition D.
remote_cpus_update() uses PERR_NOCPUS for the same kind of
subpartitions_cpus conflict:
else if (cpumask_intersects(tmp->addmask, subpartitions_cpus) ||
cpumask_subset(top_cpuset.effective_cpus,
tmp->addmask))
WRITE_ONCE(cs->prs_err, PERR_NOCPUS);
Would using PERR_NOCPUS here be more appropriate? This would keep the
initial remote-partition enable path consistent with the CPU update path
for an existing remote partition, and it also seems to describe the
failure more accurately: the CPU itself is not invalid, but has already
been allocated to another partition, so the parent can no longer
distribute it downstream.
Thanks,
Guopeng
> if (((new_prs == PRS_ISOLATED) &&
> @@ -2411,6 +2414,10 @@ static enum prs_errcode validate_partition(struct cpuset *cs, struct cpuset *tri
> if (cpumask_empty(trialcs->effective_xcpus))
> return PERR_INVCPUS;
>
> + if ((parent == &top_cpuset) &&
> + cpumask_intersects(trialcs->effective_xcpus, subpartitions_cpus))
> + return PERR_REMOTE;
> +
> if (prstate_housekeeping_conflict(trialcs->partition_root_state,
> trialcs->effective_xcpus))
> return PERR_HKEEPING;
> @@ -2970,7 +2977,7 @@ static int update_prstate(struct cpuset *cs, int new_prs)
> * local or remote partition.
> */
> if ((parent == &top_cpuset) &&
> - cpumask_intersects(cs->exclusive_cpus, subpartitions_cpus)) {
> + cpumask_intersects(user_xcpus(cs), subpartitions_cpus)) {
> err = PERR_REMOTE;
> goto out;
> }
next prev parent reply other threads:[~2026-09-20 6:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-19 22:17 [PATCH] cgroup/cpuset: prevent overlapping local and remote partition creation Hui Peng
2026-09-20 1:22 ` Ridong Chen
2026-09-20 3:04 ` Hui Peng
2026-09-20 8:23 ` [PATCH v2 1/2] cgroup/cpuset: return PERR_NOCPUS in remote_partition_enable() on subpartitions_cpus conflict Hui Peng
2026-09-20 8:23 ` [PATCH v2 2/2] cgroup/cpuset: prevent local partition activation over remote partition and sibling xcpus conflict Hui Peng
2026-09-20 8:57 ` Guopeng Zhang
2026-09-20 18:14 ` Hui Peng
2026-09-20 18:14 ` [PATCH v3 1/3] cgroup/cpuset: return PERR_NOCPUS in remote_partition_enable() Hui Peng
2026-09-20 18:14 ` [PATCH v3 2/3] cgroup/cpuset: prevent activating local partition over remote one Hui Peng
2026-09-22 20:21 ` Waiman Long
2026-09-20 18:14 ` [PATCH v3 3/3] cgroup/cpuset: check sibling effective_xcpus in cpus_excl_conflict() Hui Peng
2026-09-21 7:08 ` [PATCH v3 1/3] cgroup/cpuset: return PERR_NOCPUS in remote_partition_enable() Ridong Chen
2026-09-22 8:00 ` Hui Peng
2026-09-22 20:04 ` Waiman Long
2026-09-20 6:30 ` Guopeng Zhang [this message]
2026-09-20 8:23 ` [PATCH] cgroup/cpuset: prevent overlapping local and remote partition creation Hui Peng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=25b72fce-5354-435b-9256-482c15ae7b06@linux.dev \
--to=guopeng.zhang@linux.dev \
--cc=benquike@gmail.com \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mkoutny@suse.com \
--cc=ridong.chen@linux.dev \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.