mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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;
>  		}


  parent reply	other threads:[~2026-09-20  6:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-19 22:17 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-20 18:14           ` [PATCH v3 3/3] cgroup/cpuset: check sibling effective_xcpus in cpus_excl_conflict() Hui Peng
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®