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

On 7/23/26 07:39, Harry Yoo wrote:
> On 7/20/26 9:56 PM, [email protected] wrote:
>> 
>>> 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,

Are there any paths that actually do that?

> but not sure how it's been undiscovered for this long?

With kfree_rcu_sheaf_map we prevent the raw spinlock nesting detection in
general. But I guess if there was an actual kfree_rcu() call under any
scheduler lock involved in wakeup_kswapd(), lockdep would still trigger, right?

>> 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?
>> 
>