Re: [PATCH] mm/slab: disallow kfree_rcu_sheaf() on PREEMPT_RT again

[sashiko-bot]

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

New issues:
- [High] kfree_call_rcu_nolock() is fundamentally broken on PREEMPT_RT when called from raw spinlock contexts, and the newly added comment falsely asserts that it is safe.

Pre-existing issues:
- [Critical] Lock recursion deadlock on !PREEMPT_RT due to __GFP_KSWAPD_RECLAIM allocation under scheduler locks in kvfree_call_rcu().
- [High] Lockdep 'Invalid wait context' warning on !PREEMPT_RT kernels due to acquiring `local_trylock` while holding a `raw_spinlock_t` in `kvfree_call_rcu()`.
--

commit 2bc8f43addec97fafa1e1eee6c2edf8016a0ff92
Author: Vlastimil Babka (SUSE) <vbabka@xxxxxxxxxx>

mm/slab: disallow kfree_rcu_sheaf() on PREEMPT_RT again

This partially reverts commit 2a8bb29ec9b2 to skip kfree_rcu_sheaf() on
PREEMPT_RT from kvfree_call_rcu(). It adds a comment explaining that
local_trylock() is unsafe on PREEMPT_RT when called under pi_lock.

Link: https://syzkaller.appspot.com/bug?extid=acf142088e0182172e58
Link: https://lore.kernel.org/all/20260807-kfree_nolock_kmalloc-v1-0-ba993cbf7a60@xxxxxxxxxx/

> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index b19ba1b31484c..7223a7596dabb 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
[ ... ]
> @@ -1685,7 +1677,7 @@ static bool kfree_rcu_sheaf(void *obj)
>  
>  	s = slab->slab_cache;
>  	if (likely(!IS_ENABLED(CONFIG_NUMA) || slab_nid(slab) == numa_mem_id()))
> -		return __kfree_rcu_sheaf(s, obj, free_flags);
> +		return __kfree_rcu_sheaf(s, obj, SLAB_FREE_DEFAULT);

[Severity: Critical]
This is a pre-existing issue, but does passing SLAB_FREE_DEFAULT on
!PREEMPT_RT risk a lock recursion deadlock during low memory conditions?

When kfree_rcu_sheaf() forwards to __kfree_rcu_sheaf() with SLAB_FREE_DEFAULT,
it sets allow_spin to true. If the sheaf is empty, it calls:
    alloc_empty_sheaf(..., GFP_NOWAIT, ...)

GFP_NOWAIT implicitly includes __GFP_KSWAPD_RECLAIM. During high memory
pressure, this can trigger wakeup_kswapd(), which enters the scheduler via
try_to_wake_up() and acquires scheduler locks.

Since kvfree_call_rcu() is already called with task_struct::pi_lock held,
couldn't this allocation cause a lock recursion deadlock?

[ ... ]
> @@ -2034,7 +2026,13 @@ void kvfree_call_rcu(struct kvfree_rcu_head *head, void *ptr)
>  	if (!head)
>  		might_sleep();
>  
> -	if (kfree_rcu_sheaf(ptr))
> +	/*
> +	 * kvfree_rcu() is called by set_cpus_allowed_force() with
> +	 * task_struct::pi_lock acquired. On PREEMPT_RT the local_trylock()
> +	 * usage below will acquire the waitlock which must be avoided.
> +	 * Therefore avoid it on PREEMPT_RT.
> +	 */
> +	if (!IS_ENABLED(CONFIG_PREEMPT_RT) && kfree_rcu_sheaf(ptr))
>  		return;
>  

[Severity: High]
This isn't a bug introduced by this patch, but does executing
kfree_rcu_sheaf() on !PREEMPT_RT under pi_lock trigger a static wait-type
violation?

kvfree_rcu() is called while holding task_struct::pi_lock, which establishes
a RAW (LD_WAIT_SPIN) wait context. On !PREEMPT_RT, this code proceeds to
call kfree_rcu_sheaf(), which calls local_trylock() inside __kfree_rcu_sheaf().

Even though local_lock only disables preemption on non-RT, its lockdep map
declares an LD_WAIT_CONFIG (spinlock) wait-type. Since
CONFIG_PROVE_RAW_LOCK_NESTING statically checks declared wait-types rather
than runtime behavior, won't attempting to acquire an LD_WAIT_CONFIG lock
while holding an LD_WAIT_SPIN lock trigger an immediate "Invalid wait context"
warning on !PREEMPT_RT kernels?

> diff --git a/mm/slub.c b/mm/slub.c
> index f9b56cb439e70..7a7e906a0e44d 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -6088,8 +6088,9 @@ static void rcu_free_sheaf(struct rcu_head *head)
>  /*
>   * kvfree_call_rcu() can be called while holding a raw_spinlock_t. Since
>   * __kfree_rcu_sheaf() may acquire a spinlock_t (sleeping lock on PREEMPT_RT),
> - * this would violate lock nesting rules. Therefore, kvfree_call_rcu() avoids
> - * this problem by passing SLAB_FREE_NOLOCK on PREEMPT_RT.
> + * this would violate lock nesting rules. Therefore, kfree_call_rcu_nolock()
> + * avoids this problem by passing SLAB_FREE_NOLOCK. kvfree_call_rcu() is
> + * bypassing the sheaves layer completely on PREEMPT_RT.
>   *

[Severity: High]
Is the assertion in this comment that kfree_call_rcu_nolock() avoids the lock
nesting problem accurate for PREEMPT_RT?

Passing SLAB_FREE_NOLOCK to __kfree_rcu_sheaf() only prevents spinning, but
it still unconditionally calls local_trylock(&s->cpu_sheaves->lock). On
PREEMPT_RT, local_trylock() attempts to acquire a sleepable lock (rt_mutex),
which is an invalid wait context when held from NMI or raw spinlock contexts.

Given that kfree_call_rcu_nolock() is actively used and tested in hardirq/NMI
contexts (e.g., via test_nolock() in lib/tests/slub_kunit.c), won't this
cause a lockdep splat or kernel panic on PREEMPT_RT?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831-b4-kfree_rcu_hotfix-v1-1-4f0fb882638b@xxxxxxxxxx?part=1