From: sashiko-bot@kernel.org
Cc: linux-rt-devel@lists.linux.dev, linux-kernel@vger.kernel.org,
bpf@vger.kernel.org
Subject: Re: [PATCH for-next v3 6/9] mm/slab: allow kfree_rcu_sheaf() on PREEMPT_RT
Date: Mon, 15 Jun 2026 11:19:49 +0000 [thread overview]
Message-ID: <20260615111949.F0FC51F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260615-kfree_rcu_nolock-v3-6-70a54f3775bb@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Calling kfree_rcu_sheaf() on PREEMPT_RT from kvfree_call_rcu() causes an 'Invalid wait context' lockdep splat and potential deadlocks due to acquiring a sleeping lock from raw_spinlock, hardirq, or NMI contexts.
--
commit 67f0bb194ef2843a6fa5bfccfbb53884ff1a37b2
Author: Harry Yoo (Oracle) <harry@kernel.org>
mm/slab: allow kfree_rcu_sheaf() on PREEMPT_RT
This commit allows kfree_rcu_sheaf() to be used on kernels with
CONFIG_PREEMPT_RT by assuming that spinning is not allowed. It removes
the unconditional bailout and relaxes the limitation to try the sheaves
path.
Link: https://lore.kernel.org/linux-mm/6811cc17-8ee4-48c8-8cbf-6bf4d9f98162@kernel.org
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 55546b8385ff3..807924a94fb08 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
[ ... ]
> @@ -1954,7 +1961,7 @@ void kvfree_call_rcu(struct rcu_head *head, void *ptr)
> if (!head)
> might_sleep();
>
> - if (!IS_ENABLED(CONFIG_PREEMPT_RT) && kfree_rcu_sheaf(ptr))
> + if (kfree_rcu_sheaf(ptr))
> return;
>
> // Queue the object but don't yet schedule the batch.
[ ... ]
> diff --git a/mm/slub.c b/mm/slub.c
> index ba593c1c53d50..4850629774b2a 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
[ ... ]
> @@ -6096,10 +6097,10 @@ bool __kfree_rcu_sheaf(struct kmem_cache *s, void *obj, bool allow_spin)
> struct slub_percpu_sheaves *pcs;
> struct slab_sheaf *rcu_sheaf;
>
> - if (WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_RT)))
> - return false;
> + VM_WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_RT) && allow_spin);
>
> - lock_map_acquire_try(&kfree_rcu_sheaf_map);
> + if (!IS_ENABLED(CONFIG_PREEMPT_RT))
> + lock_map_acquire_try(&kfree_rcu_sheaf_map);
>
> if (!local_trylock(&s->cpu_sheaves->lock))
[Severity: High]
Does acquiring this local lock with CONFIG_PREEMPT_RT enabled from
kvfree_call_rcu() trigger an invalid wait context lockdep splat?
Since kvfree_call_rcu() can be called from hardirq or nmi context, or
while holding a raw_spinlock_t (like pi_lock), the caller is in a raw
spin wait context. With CONFIG_PREEMPT_RT, local_lock maps to a
spinlock_t (rt_mutex), which is a sleeping lock.
Even though this uses a trylock and allow_spin is false, acquiring a
sleeping lock under a raw spinlock or in hardirq context violates
lockdep's wait context rules because lockdep evaluates the declared wait
types of the locks, not the runtime behavior.
Additionally, could the rt_mutex trylock implementation internally attempt
to acquire the task's pi_lock, leading to a potential deadlock?
> goto fail;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-kfree_rcu_nolock-v3-0-70a54f3775bb@kernel.org?part=6
next prev parent reply other threads:[~2026-06-15 11:19 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-15 11:05 [PATCH for-next v3 0/9] mm/slab: introduce kfree_rcu_nolock() and improve slub_kunit coverage Harry Yoo (Oracle)
2026-06-15 11:05 ` [PATCH for-next v3 1/9] slub_kunit: fall back to SW perf events when HW PMU is not available Harry Yoo (Oracle)
2026-06-15 11:14 ` sashiko-bot
2026-06-15 12:58 ` Harry Yoo
2026-06-15 20:01 ` Alexei Starovoitov
2026-06-15 11:05 ` [PATCH for-next v3 2/9] mm/slab, slub_kunit: register kprobe to trigger _nolock APIs Harry Yoo (Oracle)
2026-06-15 11:25 ` sashiko-bot
2026-06-15 20:04 ` Alexei Starovoitov
2026-06-15 11:05 ` [PATCH for-next v3 3/9] mm/slab: handle the !allow_spin case in kfree_rcu_sheaf() Harry Yoo (Oracle)
2026-06-15 11:24 ` sashiko-bot
2026-06-15 11:05 ` [PATCH for-next v3 4/9] mm/slab: use call_rcu() in unknown context if irqs are enabled Harry Yoo (Oracle)
2026-06-15 11:25 ` sashiko-bot
2026-06-15 11:05 ` [PATCH for-next v3 5/9] mm/slab: extend deferred free mechanism to handle rcu sheaves Harry Yoo (Oracle)
2026-06-15 11:24 ` sashiko-bot
2026-06-15 11:06 ` [PATCH for-next v3 6/9] mm/slab: allow kfree_rcu_sheaf() on PREEMPT_RT Harry Yoo (Oracle)
2026-06-15 11:19 ` sashiko-bot [this message]
2026-06-15 11:06 ` [PATCH for-next v3 7/9] mm/slab: introduce kfree_rcu_nolock() Harry Yoo (Oracle)
2026-06-15 11:22 ` sashiko-bot
2026-06-15 11:06 ` [PATCH for-next v3 8/9] mm/slab: introduce struct kfree_rcu_head and use in kfree_rcu_nolock() Harry Yoo (Oracle)
2026-06-15 11:22 ` sashiko-bot
2026-06-15 11:06 ` [PATCH for-next v3 9/9] slub_kunit: extend the test for kfree_rcu_nolock() Harry Yoo (Oracle)
2026-06-15 11:43 ` [PATCH for-next v3 0/9] mm/slab: introduce kfree_rcu_nolock() and improve slub_kunit coverage Harry Yoo
2026-06-15 20:28 ` Alexei Starovoitov
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=20260615111949.F0FC51F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
/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.