All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ridong Chen <ridong.chen@linux.dev>
To: Guopeng Zhang <guopeng.zhang@linux.dev>,
	longman@redhat.com, tj@kernel.org
Cc: hannes@cmpxchg.org, mkoutny@suse.com, shuah@kernel.org,
	cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org,
	Guopeng Zhang <zhangguopeng@kylinos.cn>
Subject: Re: [PATCH v2 3/3] cgroup/cpuset: Release isolated CPUs when the parent is invalid
Date: Fri, 6 Nov 2026 12:35:04 +0800	[thread overview]
Message-ID: <41a6de2b-e7eb-4574-a698-b4ff8af316fa@linux.dev> (raw)
In-Reply-To: <20261105130344.664336-4-guopeng.zhang@linux.dev>



On 11/5/2026 9:03 PM, Guopeng Zhang wrote:
> From: Guopeng Zhang <zhangguopeng@kylinos.cn>
> 
> An isolated partition can be invalidated after its parent has already
> become invalid. update_parent_effective_cpumask() then skips returning
> CPUs to the parent, but also skips removing them from isolated_cpus.
> The invalid child continues to isolate CPUs that no longer belong to
> any valid isolated partition.
> 
> For example, on a 32-CPU system with all CPUs online and without
> isolcpus= or nohz_full= boot parameters:
> 
>    cd /sys/fs/cgroup
>    echo +cpuset > cgroup.subtree_control
>    mkdir A
>    echo 0,2-31 > A/cpuset.cpus
>    echo root > A/cpuset.cpus.partition
>    echo +cpuset > A/cgroup.subtree_control
>    mkdir A/B
>    echo 2-3 > A/B/cpuset.cpus
>    echo isolated > A/B/cpuset.cpus.partition
>    cat cpuset.cpus.isolated
>    2-3
>    echo 0 > /sys/devices/system/cpu/cpu1/online
>    cat A/B/cpuset.cpus.partition
>    isolated invalid
>    cat cpuset.cpus.isolated
>    2-3
> 
> Release the invalidated child's isolated CPUs when its parent is no
> longer a valid partition. Use isolated_cpus_release() to preserve CPUs
> still covered by a valid isolated ancestor and by boot isolation.
> 
> After this fix, cpuset.cpus.isolated is empty for this reproducer.
> 
> Fixes: 11e5f407b64a ("cgroup/cpuset: Keep track of CPUs in isolated partitions")
> Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
> ---
>   kernel/cgroup/cpuset.c | 7 ++++++-
>   1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index fc5454c2740f..f3b808cea51c 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -1976,10 +1976,15 @@ static int update_parent_effective_cpumask(struct cpuset *cs, int cmd,
>   		/*
>   		 * Make the current partition invalid.
>   		 */
> -		if (is_partition_valid(parent))
> +		if (is_partition_valid(parent)) {
>   			adding = cpumask_and(tmp->addmask,
>   					     cs->effective_xcpus,
>   					     parent->effective_xcpus);
> +		} else if (old_prs == PRS_ISOLATED) {
> +			/* No valid parent will release these isolated CPUs. */
> +			cpumask_copy(tmp->addmask, cs->effective_xcpus);
> +			isolated_cpus_release(cs, tmp->addmask);
> +		}
>   		if (old_prs > 0)
>   			new_prs = -old_prs;
>   

Hi Guopeng,

Thanks for the fix. Could you try this patch to see if it fixes the
issue?

https://lore.kernel.org/cgroups/20261105125215.2205892-4-ridong.chen@linux.dev/T/#u

I'm concerned about whether the related issue has been fixed in all
the places that need fixing. In your reproducer, CPUs 2-3 are already
wrong when A becomes invalid: partition_xcpus_del() only updates
isolated_cpus when the old state differs from the parent's state, so
the CPUs that A gave back but had distributed to the isolated child B
are left in isolated_cpus. This patch only cleans them up later, when
B is invalidated with an invalid parent. Other paths that give back
CPUs of an isolated descendant may have the same problem.

My patch makes partition_xcpus_del() always set the isolation state of
the given back CPUs, including those of the descendants, to the state
of the parent that receives them. With it, isolated_cpus_release()
should no longer be needed.

It would also be good to add your reproducer to test_cpuset_prs.sh.
It can be expressed with O1=0 in the test matrix.

-- 
Best regards
Ridong


  reply	other threads:[~2026-11-06  4:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-05 13:03 [PATCH v2 0/3] cgroup/cpuset: Keep the top scheduling domain populated Guopeng Zhang
2026-11-05 13:03 ` [PATCH v2 1/3] cgroup/cpuset: Reject updates that empty the top sched domain Guopeng Zhang
2026-11-06 17:22   ` Waiman Long
2026-11-09  4:42     ` Guopeng Zhang
2026-11-09 14:41       ` Waiman Long
2026-11-05 13:03 ` [PATCH v2 2/3] cgroup/cpuset: Keep the top sched domain non-empty on CPU hotplug Guopeng Zhang
2026-11-05 13:03 ` [PATCH v2 3/3] cgroup/cpuset: Release isolated CPUs when the parent is invalid Guopeng Zhang
2026-11-06  4:35   ` Ridong Chen [this message]
2026-11-06  7:35     ` Guopeng Zhang

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=41a6de2b-e7eb-4574-a698-b4ff8af316fa@linux.dev \
    --to=ridong.chen@linux.dev \
    --cc=cgroups@vger.kernel.org \
    --cc=guopeng.zhang@linux.dev \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mkoutny@suse.com \
    --cc=shuah@kernel.org \
    --cc=tj@kernel.org \
    --cc=zhangguopeng@kylinos.cn \
    /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.