From: Sasha Levin <sashal@kernel.org>
To: stable@vger.kernel.org
Cc: Qing Wang <wangqing7171@gmail.com>,
"Vlastimil Babka (SUSE)" <vbabka@kernel.org>,
Sasha Levin <sashal@kernel.org>
Subject: [PATCH 6.18.y] mm/slub: hold cpus_read_lock around flush_rcu_sheaves_on_cache()
Date: Mon, 1 Jun 2026 07:05:09 -0400 [thread overview]
Message-ID: <20260601110509.447056-1-sashal@kernel.org> (raw)
In-Reply-To: <2026052843-flavoring-boat-ccba@gregkh>
From: Qing Wang <wangqing7171@gmail.com>
[ Upstream commit 67ea9d353d0ba12bdbc9183ff568dead9e949b80 ]
flush_rcu_sheaves_on_cache() calls queue_work_on() in a
for_each_online_cpu() loop, which requires the cpu to stay online.
But cpus_read_lock() is not held in kvfree_rcu_barrier_on_cache() and the
set of "online cpus" is subject to change.
There are two paths that call flush_rcu_sheaves_on_cache():
// has cpus_read_lock()
flush_all_rcu_sheaves()
-> flush_rcu_sheaves_on_cache()
// no cpus_read_lock()
kvfree_rcu_barrier_on_cache()
-> flush_rcu_sheaves_on_cache()
Fix this by holding cpus_read_lock() in kvfree_rcu_barrier_on_cache().
Why not move cpus_read_lock() from flush_all_rcu_sheaves() into
flush_rcu_sheaves_on_cache()? The reason is it would introduce a new lock
order (slab_mutex -> cpu_hotplug_lock). The reverse order
(cpu_hotplug_lock -> slab_mutex) is established by
- cpuhp_setup_state_nocalls(..., slub_cpu_setup, ...)
- kmem_cache_destroy()
The two orders together would form an AB-BA deadlock.
Finally, add lockdep_assert_cpus_held() in flush_rcu_sheaves_on_cache()
to catch the same problem in the future.
Fixes: 0f35040de593 ("mm/slab: introduce kvfree_rcu_barrier_on_cache() for cache destruction")
Cc: <stable@vger.kernel.org>
Signed-off-by: Qing Wang <wangqing7171@gmail.com>
Link: https://patch.msgid.link/20260512035035.762317-1-wangqing7171@gmail.com
Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
mm/slab_common.c | 2 ++
mm/slub.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 0f58265ca200e..04583044a2bf0 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -2135,7 +2135,9 @@ EXPORT_SYMBOL_GPL(kvfree_rcu_barrier);
void kvfree_rcu_barrier_on_cache(struct kmem_cache *s)
{
if (s->cpu_sheaves) {
+ cpus_read_lock();
flush_rcu_sheaves_on_cache(s);
+ cpus_read_unlock();
rcu_barrier();
}
diff --git a/mm/slub.c b/mm/slub.c
index a89df6ddcc587..5fdec3b837060 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -4203,6 +4203,7 @@ void flush_rcu_sheaves_on_cache(struct kmem_cache *s)
struct slub_flush_work *sfw;
unsigned int cpu;
+ lockdep_assert_cpus_held();
mutex_lock(&flush_lock);
for_each_online_cpu(cpu) {
--
2.53.0
prev parent reply other threads:[~2026-06-01 11:05 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-28 11:45 FAILED: patch "[PATCH] mm/slub: hold cpus_read_lock around" failed to apply to 6.18-stable tree gregkh
2026-06-01 11:05 ` Sasha Levin [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=20260601110509.447056-1-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=vbabka@kernel.org \
--cc=wangqing7171@gmail.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