Re: [PATCH v5 5/8] mm/slab: allow kfree_rcu_sheaf() on PREEMPT_RT

Thank you for your contribution! Sashiko AI review found 2 potential issue(=
s) to consider:

New issues:
- [High] Calling kvfree_call_rcu() or kfree_rcu() on PREEMPT_RT under a raw=
 spinlock or hardirq context triggers a lockdep 'Invalid wait context' warn=
ing and potential deadlocks due to unconditional local_trylock() acquisitio=
n.

Pre-existing issues:
- [High] Allocating memory with GFP_NOWAIT inside __kfree_rcu_sheaf() can d=
eadlock on scheduler locks via kswapd wakeup.
--

--- Patch [5]: [PATCH v5 5/8] mm/slab: allow kfree_rcu_sheaf() on PREEMPT_R=
T ---
commit 2f2c22c6e4b6eb6bae0d210e9892e5c589edbd06
Author: Harry Yoo (Oracle) <[email protected]>

mm/slab: allow kfree_rcu_sheaf() on PREEMPT_RT

This patch enables kfree_rcu_sheaf() on PREEMPT_RT by passing
SLAB_FREE_NOLOCK when on PREEMPT_RT, avoiding spinning. It skips
the lockdep map on PREEMPT_RT to avoid suppressing valid warnings.

Link: https://lore.kernel.org/linux-mm/6811cc17-8ee4-48c8-8cbf-6bf4d9f98162=
@kernel.org [1]
Link: https://lore.kernel.org/linux-mm/40591888-3a87-433e-b3d2-cda1cab543be=
@kernel.org [2]

diff --git a/mm/slab_common.c b/mm/slab_common.c
index d81cc2136c688..9c2cca9add893 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
[ ... ]
@@ -1987,7 +1995,7 @@ void kvfree_call_rcu(struct rcu_head *head, void *ptr)
 	if (!head)
 		might_sleep();
=20
-	if (!IS_ENABLED(CONFIG_PREEMPT_RT) && kfree_rcu_sheaf(ptr))
+	if (kfree_rcu_sheaf(ptr))
 		return;
=20
 	// Queue the object but don't yet schedule the batch.
diff --git a/mm/slub.c b/mm/slub.c
index 92c99ff34a2c9..6c81722afb18c 100644
--- a/mm/slub.c
+++ b/mm/slub.c
[ ... ]
@@ -6100,10 +6101,10 @@ bool __kfree_rcu_sheaf(struct kmem_cache *s, void *=
obj, unsigned int free_flags)
 	struct slab_sheaf *rcu_sheaf;
 	bool allow_spin =3D free_flags_allow_spinning(free_flags);
=20
-	if (WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_RT)))
-		return false;
+	VM_WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_RT) && allow_spin);
=20
-	lock_map_acquire_try(&kfree_rcu_sheaf_map);
+	if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+		lock_map_acquire_try(&kfree_rcu_sheaf_map);
=20
 	if (!local_trylock(&s->cpu_sheaves->lock))

[Severity: High]
Does this unconditionally acquire a sleepable RT-mutex on PREEMPT_RT?

Since this patch removes the !IS_ENABLED(CONFIG_PREEMPT_RT) safeguard in
kvfree_call_rcu(), kfree_rcu_sheaf() can now reach this local_trylock() on
PREEMPT_RT.

kvfree_call_rcu() is frequently called from hardirq or raw spinlock context=
s.
On PREEMPT_RT, local_trylock() maps to an RT-mutex. Acquiring it from these
contexts will trigger a lockdep Invalid wait context warning.

Furthermore, if a hardirq interrupts the CPU while it already holds the
RT-mutex's internal raw wait_lock, can this trylock self-deadlock?

[Severity: High]
This is a pre-existing issue, but can the empty sheaf allocation in this
function deadlock on scheduler locks?

Further down in __kfree_rcu_sheaf(), the code does:

    gfp_t gfp =3D allow_spin ? GFP_NOWAIT : __GFP_NOWARN;
    ...
    empty =3D alloc_empty_sheaf(s, gfp, alloc_flags);

When allow_spin is true, this uses GFP_NOWAIT, which includes the
__GFP_KSWAPD_RECLAIM bit.

If kvfree_call_rcu() is called from scheduler code holding pi_lock or
rq_lock, and the allocation falls back to the page allocator, it will invoke
wakeup_kswapd(). This enters the scheduler via try_to_wake_up() and
attempts to acquire pi_lock or rq_lock again, causing a self-deadlock.

Should this use a bare flag like __GFP_NOWARN without reclaim bits?

>  		goto fail;

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260729-kfree_rcu_=
[email protected]?part=3D5