From: Guopeng Zhang <guopeng.zhang@linux.dev>
To: Waiman Long <longman@redhat.com>, Tejun Heo <tj@kernel.org>,
Ridong Chen <ridong.chen@linux.dev>
Cc: "Johannes Weiner" <hannes@cmpxchg.org>,
"Michal Koutný" <mkoutny@suse.com>,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
"Guopeng Zhang" <zhangguopeng@kylinos.cn>
Subject: Re: [PATCH 1/2] cgroup/cpuset: Fix cpuset.cpus update in a remote partition
Date: Thu, 22 Oct 2026 13:50:24 +0800 [thread overview]
Message-ID: <6bbd6b27-a417-436e-aeba-1199626c3c6f@linux.dev> (raw)
In-Reply-To: <0514f986-c125-4a2a-8079-cbbfe5cdc273@redhat.com>
在 2026/10/22 11:23, Waiman Long 写道:
> On 10/10/26 3:59 AM, Guopeng Zhang wrote:
>> From: Guopeng Zhang <zhangguopeng@kylinos.cn>
>>
>> When the CPU list of a remote partition is reduced, a removed CPU may
>> remain unavailable to the top cpuset.
>>
>> This can be reproduced on a cgroup v2 system with CPUs 0-7 online:
>>
>> cd /sys/fs/cgroup
>> echo +cpuset > cgroup.subtree_control
>> mkdir A
>> echo 1-7 > A/cpuset.cpus
>> echo 1-7 > A/cpuset.cpus.exclusive
>> echo +cpuset > A/cgroup.subtree_control
>> mkdir A/B
>> echo 1-4 > A/B/cpuset.cpus
>> echo root > A/B/cpuset.cpus.partition
>> echo 1-3 > A/B/cpuset.cpus
>> cat cpuset.cpus.effective
>>
>> The last command should show 0,4-7, but CPU 4 is missing.
>>
>> update_cpumask() calls partition_cpus_change() while cs->cpus_allowed
>> still contains the old mask. remote_cpus_update() first releases CPU 4,
>> but the hierarchy update revisits B and compute_excpus() still sees the
>> old mask, so CPU 4 is removed from the top cpuset again.
>>
>> Move the cpus_allowed update before partition_cpus_change() so that
>> the hierarchy update sees the new mask when it revisits the cpuset.
>>
>> Fixes: f62a5d39368e ("cgroup/cpuset: Remove remote_partition_check() & make update_cpumasks_hier() handle remote partition")
>> Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
>> ---
>> kernel/cgroup/cpuset.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
>> index 0ebba2d646c3..de7553459adc 100644
>> --- a/kernel/cgroup/cpuset.c
>> +++ b/kernel/cgroup/cpuset.c
>> @@ -2478,10 +2478,13 @@ static int update_cpumask(struct cpuset *cs, struct cpuset *trialcs,
>> */
>> force = !cpumask_equal(cs->effective_xcpus, trialcs->effective_xcpus);
>> + spin_lock_irq(&callback_lock);
>> + cpumask_copy(cs->cpus_allowed, trialcs->cpus_allowed);
>> + spin_unlock_irq(&callback_lock);
>> +
>> partition_cpus_change(cs, trialcs, &tmp);
>> spin_lock_irq(&callback_lock);
>> - cpumask_copy(cs->cpus_allowed, trialcs->cpus_allowed);
>> cpumask_copy(cs->effective_xcpus, trialcs->effective_xcpus);
>> if ((old_prs > 0) && !is_partition_valid(cs))
>> reset_partition_data(cs);
>
> Sorry for the late reply.
>
> Thanks for reporting this problem. I suspect similar problem may exist with change to cpuset.cpus.exclusive as well. The root cause of this problem is the recursive call to remote_cpus_update() with the second call missing information leading to the revert of the first call. I have posted another patch to address this recursive call problem. Please take a look to see if you agree with that or not.
>
Thanks for the explanation and for looking further into the root cause.
I'll take a look at your patch and run some local tests once I've taken care of some urgent work.
Thanks,
Guopeng
next prev parent reply other threads:[~2026-10-22 5:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-10 7:59 [PATCH 0/2] cgroup/cpuset: Fix partition updates using stale CPU masks Guopeng Zhang
2026-10-10 7:59 ` [PATCH 1/2] cgroup/cpuset: Fix cpuset.cpus update in a remote partition Guopeng Zhang
2026-10-22 3:23 ` Waiman Long
2026-10-22 5:50 ` Guopeng Zhang [this message]
2026-10-10 7:59 ` [PATCH 2/2] cgroup/cpuset: Fix invalid local partition recovery Guopeng Zhang
2026-10-22 3:28 ` Waiman Long
2026-10-22 5:57 ` Guopeng Zhang
2026-10-20 2:51 ` [PATCH 0/2] cgroup/cpuset: Fix partition updates using stale CPU masks 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=6bbd6b27-a417-436e-aeba-1199626c3c6f@linux.dev \
--to=guopeng.zhang@linux.dev \
--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 \
--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.