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

[Harry Yoo <harry@kernel.org>]

On 7/23/26 6:46 PM, Vlastimil Babka (SUSE) wrote:
> On 7/23/26 07:39, Harry Yoo wrote:
>> On 7/20/26 9:56 PM, sashiko-bot@kernel.org 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?

in kernel/sched/core.c:

	/*
	 * Because this is called with p->pi_lock held, it is not possible
	 * to use kfree() here (when PREEMPT_RT=y), therefore punt to using
	 * kfree_rcu().
	 */
	kfree_rcu((union cpumask_rcuhead *)ac.user_mask, rcu);

...and try_to_wake_up acquires pi_lock.

So I'm bit puzzled :)

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

Yeah. It only overrides wait type (and tell lockdep
that it is okay to acquire a spinlock, although we're holding a raw
spinlock).

> But I guess if there was an actual kfree_rcu() call under any
> scheduler lock involved in wakeup_kswapd(), lockdep would still trigger, right?

I was assuming so, but there is one!

...I guess we should look at when the path is executed.

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