From: Waiman Long <longman@redhat.com>
To: "Ridong Chen" <ridong.chen@linux.dev>,
"Tejun Heo" <tj@kernel.org>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Michal Koutný" <mkoutny@suse.com>
Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
Sashiko <sashiko-bot@kernel.org>,
Ridong Chen <chenridong@xiaomi.com>
Subject: Re: [PATCH for-7.4-fixes] cgroup/cpuset: Don't revive invalid partition without active CPU on hotplug
Date: Sun, 15 Nov 2026 10:56:30 -0500 [thread overview]
Message-ID: <ec69f1c9-4798-47cf-b91c-ed6a9ec96ffe@redhat.com> (raw)
In-Reply-To: <20261114120532.1438512-1-ridong.chen@linux.dev>
On 11/14/26 7:05 AM, Ridong Chen wrote:
> From: Ridong Chen <chenridong@xiaomi.com>
>
> When a CPU hotplug leaves no CPU outside of the partitions for the top
> cpuset, cpuset_handle_hotplug() clears subpartitions_cpus and gives all
> the active CPUs back to the top cpuset. cpuset_hotplug_update_tasks()
> then walks the hierarchy and invalidates the partitions, as
> subpartitions_cpus is empty.
>
> However, an invalid partition visited in the same walk may be revived
> if its effective_xcpus is not empty. tasks_nocpu_error() doesn't catch
> it when its CPUs are all offline but it has no task. Its CPUs are put
> back into subpartitions_cpus, and the valid partitions visited after it
> are no longer invalidated, as subpartitions_cpus is not empty any more.
> The top cpuset is left with CPUs overlapping with these partitions.
>
> It can be reproduced on a system with 8 CPUs:
>
> # cd /sys/fs/cgroup
> # echo +cpuset > cgroup.subtree_control
> # mkdir A1 B1
> # echo 1 > A1/cpuset.cpus
> # echo 1 > A1/cpuset.cpus.exclusive
> # echo 0,2-7 > B1/cpuset.cpus
> # echo root > B1/cpuset.cpus.partition
> # echo root > A1/cpuset.cpus.partition
> # cat A1/cpuset.cpus.partition
> root invalid (Parent unable to distribute cpu downstream)
> # echo 0 > /sys/devices/system/cpu/cpu1/online
> # cat A1/cpuset.cpus.partition B1/cpuset.cpus.partition
> root
> root
> # cat cpuset.cpus.effective
> 0,2-7
>
> A1 can't take CPU 1, the last CPU of the root cgroup which has tasks.
> When CPU 1 is offlined, A1 is revived without any active CPU, and B1
> stays valid while its CPUs are also in the effective CPUs of the root
> cgroup, which triggers
>
> WARNING: kernel/cgroup/cpuset.c:919 at rebuild_sched_domains_locked
>
> Only revive an invalid partition in hotplug if its effective_xcpus has
> an active CPU, the same as what is required to create a partition with
> tasks. With that, A1 and B1 are both invalidated in the above case.
>
> Fixes: 0c7f293efc87 ("cgroup/cpuset: Add cpuset.cpus.exclusive.effective for v2")
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Link: https://sashiko.dev/#/patchset/20261114083124.1340140-1-ridong.chen%40linux.dev?part=11
> Signed-off-by: Ridong Chen <chenridong@xiaomi.com>
> ---
> kernel/cgroup/cpuset.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index 7e374210c123..bfc852090765 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -4016,10 +4016,10 @@ static void cpuset_hotplug_update_tasks(struct cpuset *cs, struct tmpmasks *tmp)
> partcmd = partcmd_invalidate;
> /*
> * On the other hand, an invalid partition root may be transitioned
> - * back to a regular one with a non-empty effective xcpus.
> + * back to a regular one if its effective xcpus has an active CPU.
> */
> else if (is_partition_valid(parent) && is_partition_invalid(cs) &&
> - !cpumask_empty(cs->effective_xcpus))
> + cpumask_intersects(cs->effective_xcpus, cpu_active_mask))
> partcmd = partcmd_update;
>
> if (partcmd >= 0) {
>
> base-commit: e234ed1bb82c96a5643fd70784f16cf3d72eeed3
Reviewed-by: Waiman Long <longman@redhat.com>
prev parent reply other threads:[~2026-11-15 15:56 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-14 12:05 [PATCH for-7.4-fixes] cgroup/cpuset: Don't revive invalid partition without active CPU on hotplug Ridong Chen
2026-11-15 15:56 ` Waiman Long [this message]
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=ec69f1c9-4798-47cf-b91c-ed6a9ec96ffe@redhat.com \
--to=longman@redhat.com \
--cc=cgroups@vger.kernel.org \
--cc=chenridong@xiaomi.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mkoutny@suse.com \
--cc=ridong.chen@linux.dev \
--cc=sashiko-bot@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox