From: Ridong Chen <ridong.chen@linux.dev>
To: "Waiman Long" <longman@redhat.com>, "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,
Guopeng Zhang <guopeng.zhang@linux.dev>,
Sashiko <sashiko-bot@kernel.org>
Subject: Re: [PATCH-next v2 3/5] cgroup/cpuset: Fix incorrect partition invalidation logic in cpuset_hotplug_update_tasks()
Date: Tue, 10 Nov 2026 16:51:55 +0800 [thread overview]
Message-ID: <44ae3718-5ed2-48a2-94ce-5068d71d6cee@linux.dev> (raw)
In-Reply-To: <20261109190955.1398611-4-longman@redhat.com>
On 11/10/2026 3:09 AM, Waiman Long wrote:
> When most of the active CPUs of a system are allocated to
> sub-partitions below the top_cpuset partition, it is possible that a
> CPU offline operation may remove the last active CPU in the top_cpuset
> partition. When that really happens, cpuset_handle_hotplug() will clear
> the subpartitions_cpus to make sure active CPUs are present in the top
> partition and let the other sub-partitions get invalidated and then
> competes for their exclusive CPUs again.
>
> In cpuset_hotplug_update_tasks(), the current code use
> "cpumask_empty(subpartitions_cpus)" to determine if that partition
> should be invalidated. That is fine if there is only one sub-partition.
> As reported by sashiko that when there are more than one sub-partitions
> and the first sub-partition will get invalidated and then it will
> try to acquire the exclusive CPUs and become valid again. When this
> happens, the subpartitions_cpus will no longer be empty. The remaining
> sub-partitions will assume their exclusive CPUs are safe and proceed
> as normal. As a result, active CPUs owned by those sub-partitions
> remain in both top_cpuset.effective_cpus and the sub-partitions'
> effective_cpus while missing from subpartitions_cpus, breaking partition
> CPU exclusivity and triggering WARN_ON_ONCE() in generate_sched_domains()
> and remote_partition_disable().
>
> Fix that by checking if the sub-partitions' effective_xcpus are subset
> of subpartitions_cpus to determine if they should be invalidated. Also
> remove the obsolete WARN_ON_ONCE() call in remote_partition_disable().
>
> Fixes: 0c7f293efc87 ("cgroup/cpuset: Add cpuset.cpus.exclusive.effective for v2")
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Link: https://sashiko.dev/#/bug/linux-bf69cd3c-833a-4599-a1f9-8dd9e044cd7c
> Signed-off-by: Waiman Long <longman@redhat.com>
> ---
> kernel/cgroup/cpuset.c | 19 +++++--------------
> 1 file changed, 5 insertions(+), 14 deletions(-)
>
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index 3955d2d574cf..e9b84671af21 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -1766,15 +1766,6 @@ static int remote_partition_enable(struct cpuset *cs, int new_prs,
> static void remote_partition_disable(struct cpuset *cs, struct tmpmasks *tmp)
> {
> WARN_ON_ONCE(!is_remote_partition(cs));
> - /*
> - * When a CPU is offlined, top_cpuset may end up with no available CPUs,
> - * which should clear subpartitions_cpus. We should not emit a warning for this
> - * scenario: the hierarchy is updated from top to bottom, so subpartitions_cpus
> - * may already be cleared when disabling the partition.
> - */
> - WARN_ON_ONCE(!cpumask_subset(cs->effective_xcpus, subpartitions_cpus) &&
> - !cpumask_empty(subpartitions_cpus));
> -
> spin_lock_irq(&callback_lock);
> cs->remote_partition = false;
> partition_xcpus_del(cs->partition_root_state, NULL, cs->effective_xcpus);
> @@ -4020,9 +4011,9 @@ static void cpuset_hotplug_update_tasks(struct cpuset *cs, struct tmpmasks *tmp)
> * or update_parent_effective_cpumask() is called as cs->effective_cpus
> * may have been updated.
> */
> - if (is_remote_partition(cs) && (cpumask_empty(subpartitions_cpus) ||
> - (cpumask_empty(&new_cpus) &&
> - partition_is_populated(cs, NULL)))) {
> + if (is_remote_partition(cs) &&
> + (!cpumask_subset(cs->effective_xcpus, subpartitions_cpus) ||
> + (cpumask_empty(&new_cpus) && partition_is_populated(cs, NULL)))) {
> WRITE_ONCE(cs->prs_err, PERR_HOTPLUG);
> remote_partition_disable(cs, tmp);
> compute_effective_cpumask(&new_cpus, cs, parent);
> @@ -4035,12 +4026,12 @@ static void cpuset_hotplug_update_tasks(struct cpuset *cs, struct tmpmasks *tmp)
> * 1) empty effective cpus but not valid empty partition.
> * 2) parent is invalid or doesn't grant any cpus to child
> * partitions.
> - * 3) subpartitions_cpus is empty.
> + * 3) effective_xcpus isn't a subset of subpartitions_cpus.
> */
> if (is_local_partition(cs) &&
> (!is_partition_valid(parent) ||
> tasks_nocpu_error(parent, cs, &new_cpus) ||
> - cpumask_empty(subpartitions_cpus)))
> + !cpumask_subset(cs->effective_xcpus, subpartitions_cpus)))
> partcmd = partcmd_invalidate;
> /*
> * On the other hand, an invalid partition root may be transitioned
LGTM.
Reviewed-by: Ridong Chen <ridong.chen@linux.dev>
Thanks.
--
Best regards
Ridong
next prev parent reply other threads:[~2026-11-10 8:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 19:09 [PATCH-next v2 0/5] More fix patches Waiman Long
2026-11-09 19:09 ` [PATCH-next v2 1/5] selftests/cgroup: Fix "test_cpuset_prs.sh -v" failures Waiman Long
2026-11-10 7:56 ` Ridong Chen
2026-11-09 19:09 ` [PATCH-next v2 2/5] cgroup/cpuset: Correctly set cpus_updated in cpuset_hotplug_update_tasks() Waiman Long
2026-11-10 8:40 ` Ridong Chen
2026-11-11 2:01 ` Waiman Long
2026-11-09 19:09 ` [PATCH-next v2 3/5] cgroup/cpuset: Fix incorrect partition invalidation logic " Waiman Long
2026-11-10 8:51 ` Ridong Chen [this message]
2026-11-09 19:09 ` [PATCH-next v2 4/5] cgroup/cpuset: Protect current->mems_allowed read in cpuset_fork() Waiman Long
2026-11-10 11:24 ` Ridong Chen
2026-11-09 19:09 ` [PATCH-next v2 5/5] cgroup/cpuset: Correctly set isolated_cpus when switching partition state Waiman Long
2026-11-10 2:23 ` Waiman Long
2026-11-10 2:24 ` [PATCH-next v2.1 " Waiman Long
2026-11-10 11:40 ` [PATCH-next v2 " Ridong Chen
2026-11-10 13:02 ` Ridong Chen
2026-11-10 19:27 ` [PATCH-next v2 0/5] More fix patches Tejun Heo
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=44ae3718-5ed2-48a2-94ce-5068d71d6cee@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=sashiko-bot@kernel.org \
--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.