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>,
"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>,
Waiman Long <longman@redhat.com>,
Guopeng Zhang <zhangguopeng@kylinos.cn>
Subject: [PATCH-next v2 01/10] cgroup/cpuset: Find furthest isolated ancestor for invalidated isolated partition
Date: Fri, 23 Oct 2026 16:00:27 -0400 [thread overview]
Message-ID: <20261023200036.60560-2-longman@redhat.com> (raw)
In-Reply-To: <20261023200036.60560-1-longman@redhat.com>
Commit 46b885416c27 ("cgroup/cpuset: Fix a missing isolated_cpus
update in update_cpumasks_hier()") searches for the closet partition
root ancestor to determine if the isolated CPUs in a to be invalidated
isolation partition should be removed from isolated_cpus or not.
As reported by sashiko, this method may not work when there is a deeply
nested isolated partition hierarchy. For instance, Consider a nested
hierarchy A0 -> A1 -> A2 -> A3 where all four are PRS_ISOLATED:
A0: effective_xcpus = 0-4
A1: effective_xcpus = 1-4
A2: effective_xcpus = 2-4
A3: effective_xcpus = 3-4
When A1 shrinks its exclusive_cpus from 1-4 to 1-2, A2 will update it
effective_xcpus to 2. A3 will find its closet partition root ancestor
A2 and decides that its effective_xcpus 3-4 should be removed from
isolated_cpus which is incorrect.
Address this corner case by searching for the furthest isolated partition
root ancestor instead to decide if its isolated CPUs should be returned
to isolated_cpus.
There are other pre-existing problems that will still prevent the
above test case to work correctly. These problems will be addressed in
subsequent patches.
Reviewed-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
Tested-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
Reviewed-by: Ridong Chen <ridong.chen@linux.dev>
Fixes: 46b885416c27 ("cgroup/cpuset: Fix a missing isolated_cpus update in update_cpumasks_hier()")
Signed-off-by: Waiman Long <longman@redhat.com>
---
kernel/cgroup/cpuset.c | 36 +++++++++++++++++-------------------
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index 585a982249ad..1ca548cd50fd 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -2156,22 +2156,20 @@ static void compute_partition_effective_cpumask(struct cpuset *cs,
}
/*
- * ancestor_partition - Find and return the closest valid partition root ancestor
+ * furthest isolated_ancestor - Return furthest isolated partition root ancestor available
* @cs: the current cpuset
- *
- * Return: The closet partition root ancestor cpuset
+ * Return: The furthest isolated partition root ancestor available or NULL if
+ * not found.
*/
-static struct cpuset *ancestor_partition(struct cpuset *cs)
+static struct cpuset *furthest_isolated_ancestor(struct cpuset *cs)
{
struct cpuset *ancestor = parent_cs(cs);
+ struct cpuset *iancestor = NULL;
- /*
- * The top_cpuset is always a valid partition root which will stop
- * the loop if it is reached.
- */
- while (!is_partition_valid(ancestor))
- ancestor = parent_cs(ancestor);
- return ancestor;
+ for (; ancestor; ancestor = parent_cs(ancestor))
+ if (ancestor->partition_root_state == PRS_ISOLATED)
+ iancestor = ancestor;
+ return iancestor;
}
/*
@@ -2283,23 +2281,23 @@ static void update_cpumasks_hier(struct cpuset *cs, struct tmpmasks *tmp,
* For a to be invalidated isolated partition,
* its isolated CPUs may or may not need to be
* removed from isolated_cpus depending on if
- * its closest partition root ancestor is a root
- * or isolated partition. With a PRS_ISOLATED
- * ancestor, the CPUs are checked against its
- * effective xcpus to see if any of them needed
- * to be removed.
+ * there is a furthest isolated partition root
+ * ancestor available. When such a PRS_ISOLATED
+ * ancestor is available, the CPUs are checked
+ * against its effective xcpus to see if any of
+ * them needed to be removed.
*/
if (is_partition_valid(cp))
new_prs = -old_prs;
if (old_prs == PRS_ISOLATED) {
- struct cpuset *ancestor = ancestor_partition(cp);
+ struct cpuset *iancestor = furthest_isolated_ancestor(cp);
- if (ancestor->partition_root_state == PRS_ROOT)
+ if (!iancestor)
del_cpus = cp->effective_xcpus;
else if (cpumask_andnot(tmp->delmask,
cp->effective_xcpus,
- ancestor->effective_xcpus))
+ iancestor->effective_xcpus))
del_cpus = tmp->delmask;
if (del_cpus) {
--
2.56.0
next prev parent reply other threads:[~2026-10-23 20:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-23 20:00 [PATCH-next v2 00/10] cgroup/cpuset: Miscellaneous bug fixes & cleanup Waiman Long
2026-10-23 20:00 ` Waiman Long [this message]
2026-10-23 20:00 ` [PATCH-next v2 02/10] cgroup/cpuset: Properly compute effective xcpus in update_parent_effective_cpumask() Waiman Long
2026-10-23 20:00 ` [PATCH-next v2 03/10] cgroup/cpuset: Fix incorrect effective_cpus bug in update_cpumasks_hier() Waiman Long
2026-10-23 20:00 ` [PATCH-next v2 04/10] cgroup/cpuset: Minor fixes to prstate_housekeeping_conflict() Waiman Long
2026-10-23 20:00 ` [PATCH-next v2 05/10] selftests/cgroup: Check for a single range nohz_full CPUs before running test matrix Waiman Long
2026-10-23 20:00 ` [PATCH-next v2 06/10] cgroup/cpuset: Prevent recursive call of remote_cpus_update() via update_cpumasks_hier() Waiman Long
2026-10-23 20:00 ` [PATCH-next v2 07/10] cgroup/cpuset: Make sure compute_partition_effective_cpumask() is only called for valid partition Waiman Long
2026-10-23 20:00 ` [PATCH-next v2 08/10] cgroup/cpuset: Update isolated_cpus if necessary in compute_partition_effective_cpumask() Waiman Long
2026-10-23 20:00 ` [PATCH-next v2 09/10] cgroup/cpuset: Relocate compute_*effective_cpumask() and compute_effective_nodemask() Waiman Long
2026-10-23 20:00 ` [PATCH-next v2 10/10] cgroup/cpuset: Integrate compute_partition_effective_cpumask() into compute_effective_cpumask() Waiman Long
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=20261023200036.60560-2-longman@redhat.com \
--to=longman@redhat.com \
--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=mkoutny@suse.com \
--cc=ridong.chen@linux.dev \
--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.