Re: [PATCH slab/for-next v4 5/8] mm/slab: allow kfree_rcu_sheaf() on PREEMPT_RT

[Harry Yoo <harry@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2841 bytes --]



On 7/20/26 9:56 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> 
> New issues:
> - [High] Calling `local_trylock()` inside `kvfree_call_rcu()` on PREEMPT_RT violates lockdep wait-type nesting rules and is unsafe in hardirq/NMI context.
> 
> Pre-existing issues:
> - [High] Preexisting bug: Using GFP_NOWAIT in __kfree_rcu_sheaf() can cause lock recursion deadlocks when called under scheduler locks.
> --
> 
> --- Patch [5]: [PATCH slab/for-next v4 5/8] mm/slab: allow kfree_rcu_sheaf() on PREEMPT_RT ---
> commit 9ccf08cd866ca28e999f59be7998db3bfc32fb7a
> Author: Harry Yoo (Oracle) <harry@kernel.org>
> Subject: mm/slab: allow kfree_rcu_sheaf() on PREEMPT_RT
> 
> This patch allows kfree_rcu_sheaf() to be used on PREEMPT_RT by setting
> SLAB_FREE_NOLOCK when PREEMPT_RT is enabled. It relaxes the limitation
> in kvfree_call_rcu() and skips the lockdep wait-type override 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/slub.c b/mm/slub.c
>> index 8afa6b47b1f2b..deac315d0f23e 100644
>> --- a/mm/slub.c
>> +++ b/mm/slub.c
> [ ... ]
>> @@ -6080,10 +6081,10 @@ bool __kfree_rcu_sheaf(struct kmem_cache *s, void *obj, unsigned int free_flags)
>>  	struct slab_sheaf *rcu_sheaf;
>>  	bool allow_spin = free_flags_allow_spinning(free_flags);
>>  
>> -	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]
> This is a pre-existing issue, but since we are enabling this path for
> PREEMPT_RT, does the use of GFP_NOWAIT later in this function cause
> lock recursion deadlocks?
> 
> When the fast path fails, __kfree_rcu_sheaf() calls:
> 
>     empty = alloc_empty_sheaf(s, GFP_NOWAIT, alloc_flags);
> 
> GFP_NOWAIT includes __GFP_KSWAPD_RECLAIM, which invokes wakeup_kswapd().
> The wake-up path enters the scheduler via try_to_wake_up() and attempts to
> acquire scheduler locks like pi_lock and the runqueue lock.

This indeed looks like a real issue as kfree_rcu() can be called under
scheduler locks, but not sure how it's been undiscovered for this long?

> If kvfree_call_rcu() was called while the CPU already holds these scheduler
> locks, will this wake-up attempt cause a lock recursion self-deadlock?
> 

-- 
Cheers,
Harry / Hyeonggon

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]