From: Guopeng Zhang <guopeng.zhang@linux.dev>
To: "Waiman Long" <longman@redhat.com>,
"Ridong Chen" <ridong.chen@linux.dev>,
"Tejun Heo" <tj@kernel.org>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Michal Koutný" <mkoutny@suse.com>,
"Shuah Khan" <shuah@kernel.org>
Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH-next 2/6] cgroup/cpuset: Properly compute effective xcpus in update_parent_effective_cpumask()
Date: Fri, 23 Oct 2026 09:41:29 +0800 [thread overview]
Message-ID: <0f191ffa-450a-4b0d-b2b6-7d29149d7f13@linux.dev> (raw)
In-Reply-To: <00130aa2-2f85-4c4f-8283-acfa6df7cae5@redhat.com>
在 2026/10/22 22:47, Waiman Long 写道:
> On 10/22/26 9:45 AM, Guopeng Zhang wrote:
>> Hi Longman,
>>
>> 在 2026/10/22 11:16, Waiman Long 写道:
>>> Since the introduction of cpuset.cpus.exclusive in commit
>>> e2ffe502ba45 ("cgroup/cpuset: Add cpuset.cpus.exclusive for v2"), a
>>> compute_effective_exclusive_cpumask() helper which is later renamed to
>>> compute_excpus() is added to compute the effective xcpus of a partition
>>> root. However update_parent_effective_cpumask() is not updated in all
>>> proper places to use the new helper to check if a given cpuset should
>>> remain a valid partition root. This can cause a cpuset to incorrectly
>>> remain a valid partition root even if no effective xcpus is left.
>>>
>>> Fix that problem by using compute_excpus() to compute the effective xcpus
>>> into delmask in all cases except partcmd_disable and partcmd_invalidate
>>> and use it for tasks_nocpu_error() check as well as checking its
>>> emptiness. This enables us to catch invalid partition root more
>>> accurately in update_parent_effective_cpumask().
>>>
>> I re-tested the repro from the link below on top of this series
>> (applied on cgroup/for-7.4-fixes), and it still fails:
>>
>> https://lore.kernel.org/all/20261010075947.333549-3-guopeng.zhang@linux.dev/
>>
>> cd /sys/fs/cgroup
>> echo +cpuset > cgroup.subtree_control
>> mkdir A
>> echo 0-7 > A/cpuset.cpus
>> echo 0-7 > A/cpuset.cpus.exclusive
>> echo root > A/cpuset.cpus.partition
>> cat A/cpuset.cpus.partition
>> echo 1 > A/cpuset.cpus.exclusive
>> cat A/cpuset.cpus.partition
>>
>> The last command still shows "root invalid (Parent unable to distribute
>> cpu downstream)".
>>
>> In this case compute_excpus() returns the stale user mask unchanged.
>> user_xcpus() is gone from update_parent_effective_cpumask(), but the
>> dependency just moved one level down: the new code calls
>> compute_excpus(cs, tmp->delmask), and its first line is
>>
>> cpumask_and(excpus, user_xcpus(cs), parent->effective_xcpus)
>>
>> Here user_xcpus(cs) is cs->exclusive_cpus, which still holds the old
>> 0-7 when compute_excpus() runs: update_exclusive_cpumask() publishes
>> cs->exclusive_cpus only after partition_cpus_change(). Nothing corrects
>> it either - the sibling trim is skipped as exclusive_cpus is non-empty,
>> and for a direct child of the root cpuset the intersection with
>> parent->effective_xcpus is a no-op. So the stale 0-7 mask still reaches
>> tasks_nocpu_error() and PERR_NOCPUS is set again. Please point it out
>> if I got the analysis wrong.
>>
>> I have rebased my fix on top of this series and the partition recovers
>> correctly with it applied. Should the fix be folded into this patch,
>> or is there a better way to fix it? Happy to hear your thoughts.
> OK, I will look into that again.
>>
>> Also, is the test case below worth adding here as well? Note that it
>> fails until the fix is in:
>>
>> # An invalid local partition that took all the CPUs from its
>> # populated parent should recover after its cpuset.cpus.exclusive
>> # list is changed to a valid one.
>> "C0-7:X0-7:P1 . . . X1 . . . 0 A1:1|XA1:1 A1:P1 ."
>
> This test case assumes that there are only 8 CPUs in the test system which may not be true in many cases. We need test case that will work no matter the system it is running on.
>
You are right, I wasn't thinking clearly and missed that rule.
Thanks,
Guopeng
next prev parent reply other threads:[~2026-10-23 1:41 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 3:16 [PATCH-next 0/6] cgroup/cpuset: Miscellaneous bug fixes Waiman Long
2026-10-22 3:16 ` [PATCH-next 1/6] cgroup/cpuset: Find furthest isolated ancestor for invalidated isolated partition Waiman Long
2026-10-22 13:25 ` Guopeng Zhang
2026-10-22 16:19 ` Waiman Long
2026-10-23 6:24 ` Ridong Chen
2026-10-23 16:48 ` Waiman Long
2026-10-22 3:16 ` [PATCH-next 2/6] cgroup/cpuset: Properly compute effective xcpus in update_parent_effective_cpumask() Waiman Long
2026-10-22 13:45 ` Guopeng Zhang
2026-10-22 14:47 ` Waiman Long
2026-10-23 1:41 ` Guopeng Zhang [this message]
2026-10-22 15:00 ` Waiman Long
2026-10-23 1:53 ` Guopeng Zhang
2026-10-23 20:45 ` Waiman Long
2026-10-26 5:46 ` Guopeng Zhang
2026-10-23 6:45 ` Ridong Chen
2026-10-23 16:56 ` Waiman Long
2026-10-23 7:42 ` Guopeng Zhang
2026-10-22 3:16 ` [PATCH-next 3/6] cgroup/cpuset: Fix incorrect effective_cpus bug in update_cpumasks_hier() Waiman Long
2026-10-23 7:07 ` Ridong Chen
2026-10-23 17:01 ` Waiman Long
2026-10-22 3:16 ` [PATCH-next 4/6] cgroup/cpuset: Minor fixes to prstate_housekeeping_conflict() Waiman Long
2026-10-22 14:15 ` Guopeng Zhang
2026-10-22 14:35 ` Waiman Long
2026-10-22 3:16 ` [PATCH-next 5/6] selftests/cgroup: Check for a single range nohz_full CPUs before running test matrix Waiman Long
2026-10-22 14:09 ` Guopeng Zhang
2026-10-22 3:16 ` [PATCH-next 6/6] cgroup/cpuset: Prevent recursive call of remote_cpus_update() via update_cpumasks_hier() Waiman Long
2026-10-22 14:23 ` 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=0f191ffa-450a-4b0d-b2b6-7d29149d7f13@linux.dev \
--to=guopeng.zhang@linux.dev \
--cc=cgroups@vger.kernel.org \
--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=ridong.chen@linux.dev \
--cc=shuah@kernel.org \
--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.