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>
Subject: [PATCH-next 1/6] cgroup/cpuset: Find furthest isolated ancestor for invalidated isolated partition
Date: Wed, 21 Oct 2026 23:16:38 -0400 [thread overview]
Message-ID: <20261022031643.1351877-2-longman@redhat.com> (raw)
In-Reply-To: <20261022031643.1351877-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.
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..7ead8c3b7974 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
+ * iancestor_partition - 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 *iancestor_partition(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 = iancestor_partition(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.55.0
next prev parent reply other threads:[~2026-10-22 3:17 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 ` Waiman Long [this message]
2026-10-22 13:25 ` [PATCH-next 1/6] cgroup/cpuset: Find furthest isolated ancestor for invalidated isolated partition 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
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=20261022031643.1351877-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 \
/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.