From: Daniel Wagner <wagi@kernel.org>
To: Christoph Hellwig <hch@lst.de>, Keith Busch <kbusch@kernel.org>,
Jens Axboe <axboe@kernel.dk>, Ming Lei <ming.lei@redhat.com>
Cc: Guangwu Zhang <guazhang@redhat.com>,
Chengming Zhou <zhouchengming@bytedance.com>,
Thomas Gleixner <tglx@kernel.org>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-block@vger.kernel.org, Daniel Wagner <wagi@kernel.org>
Subject: [PATCH 3/3] Revert "lib/group_cpus.c: avoid acquiring cpu hotplug lock in group_cpus_evenly"
Date: Thu, 26 Feb 2026 14:40:37 +0100 [thread overview]
Message-ID: <20260226-revert-cpu-read-lock-v1-3-eb005072566e@kernel.org> (raw)
In-Reply-To: <20260226-revert-cpu-read-lock-v1-0-eb005072566e@kernel.org>
This reverts commit 0263f92fadbb9d294d5971ac57743f882c93b2b3.
The reason the lock was removed was that the nvme-pci driver reset
handler attempted to acquire the CPU read lock during CPU hotplug
offlining (holds the CPU write lock). Consequently, the block layer
offline notifier callback could not progress because in-flight requests
were detected.
Since then, in-flight detection has been improved, and the nvme-pci
driver now explicitly updates the hctx state when it is safe to ignore
detected in-flight requests. As a result, it's possible to reintroduce
the CPU read lock in group_cpus_evenly.
Signed-off-by: Daniel Wagner <wagi@kernel.org>
---
lib/group_cpus.c | 21 +++++----------------
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/lib/group_cpus.c b/lib/group_cpus.c
index e6e18d7a49bb..533c722b5c2c 100644
--- a/lib/group_cpus.c
+++ b/lib/group_cpus.c
@@ -510,25 +510,13 @@ struct cpumask *group_cpus_evenly(unsigned int numgrps, unsigned int *nummasks)
if (!masks)
goto fail_node_to_cpumask;
+ /* Stabilize the cpumasks */
+ cpus_read_lock();
build_node_to_cpumask(node_to_cpumask);
- /*
- * Make a local cache of 'cpu_present_mask', so the two stages
- * spread can observe consistent 'cpu_present_mask' without holding
- * cpu hotplug lock, then we can reduce deadlock risk with cpu
- * hotplug code.
- *
- * Here CPU hotplug may happen when reading `cpu_present_mask`, and
- * we can live with the case because it only affects that hotplug
- * CPU is handled in the 1st or 2nd stage, and either way is correct
- * from API user viewpoint since 2-stage spread is sort of
- * optimization.
- */
- cpumask_copy(npresmsk, data_race(cpu_present_mask));
-
/* grouping present CPUs first */
ret = __group_cpus_evenly(curgrp, numgrps, node_to_cpumask,
- npresmsk, nmsk, masks);
+ cpu_present_mask, nmsk, masks);
if (ret < 0)
goto fail_node_to_cpumask;
nr_present = ret;
@@ -543,13 +531,14 @@ struct cpumask *group_cpus_evenly(unsigned int numgrps, unsigned int *nummasks)
curgrp = 0;
else
curgrp = nr_present;
- cpumask_andnot(npresmsk, cpu_possible_mask, npresmsk);
+ cpumask_andnot(npresmsk, cpu_possible_mask, cpu_present_mask);
ret = __group_cpus_evenly(curgrp, numgrps, node_to_cpumask,
npresmsk, nmsk, masks);
if (ret >= 0)
nr_others = ret;
fail_node_to_cpumask:
+ cpus_read_unlock();
free_node_to_cpumask(node_to_cpumask);
fail_npresmsk:
--
2.53.0
next prev parent reply other threads:[~2026-02-26 13:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-26 13:40 [PATCH 0/3] block: revert avoid acquiring cpu hotplug lock in group_cpus_evenly Daniel Wagner
2026-02-26 13:40 ` [PATCH 1/3] nvme: failover requests for inactive hctx Daniel Wagner
2026-02-26 19:09 ` kernel test robot
2026-02-26 23:55 ` kernel test robot
2026-02-26 13:40 ` [PATCH 2/3] blk-mq: add handshake for offlinig hw queues Daniel Wagner
2026-02-26 13:40 ` Daniel Wagner [this message]
2026-02-26 14:04 ` [PATCH 3/3] Revert "lib/group_cpus.c: avoid acquiring cpu hotplug lock in group_cpus_evenly" Ming Lei
2026-03-02 14:04 ` Daniel Wagner
2026-03-02 14:12 ` Ming Lei
2026-03-02 14:27 ` Daniel Wagner
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=20260226-revert-cpu-read-lock-v1-3-eb005072566e@kernel.org \
--to=wagi@kernel.org \
--cc=axboe@kernel.dk \
--cc=guazhang@redhat.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=ming.lei@redhat.com \
--cc=tglx@kernel.org \
--cc=zhouchengming@bytedance.com \
/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
all inboxes | Powered by JetHome®