Re: [PATCH for-next v3 6/9] mm/slab: allow kfree_rcu_sheaf() on PREEMPT_RT

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

On 6/17/26 07:14, Harry Yoo wrote:
> 
> 
> On 6/17/26 2:24 AM, Vlastimil Babka (SUSE) wrote:
>> On 6/15/26 13:06, Harry Yoo (Oracle) wrote:
>>> As suggested by Vlastimil Babka, kfree_rcu_sheaf() can be used
>>> on PREEMPT_RT if we always assume spinning is not allowed on PREEMPT_RT.
>>> This is because local_trylock and spinlock_t are safe to use with
>>> trylock variant as long as the kernel does not spin and the context is
>>> not NMI and not hardirq.
>>>
>>> Now that __kfree_rcu_sheaf() knows how to handle allow_spin = false,
>>> relax the limitation and try the sheaves path on PREEMPT_RT as well.
>>>
>>> Keep the lockdep map on non RT kernels. However, do not use the lockdep
>>> map on PREEMPT_RT to avoid suppressing valid lockdep warnings.
>>>
>>> Link: https://lore.kernel.org/linux-mm/6811cc17-8ee4-48c8-8cbf-6bf4d9f98162@kernel.org
>>> Suggested-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
>>> Signed-off-by: Harry Yoo (Oracle) <harry@kernel.org>
>> 
>> LGTM, but maybe unnecessary pessimistic wrt call_rcu() on PREEMPT_RT?
>> I thought (in the Link: above) we'd only need to downgrade allow_spin to
>> false on PREEMPT_RT for handling sheaves movement from/to barn and
>> alloc_empty_sheaf(), but call_rcu() would be safe from kfree_rcu() even on
>> RT?
> 
> Indeed. Good point, thanks!
> 
> Hmm, but I'm not sure that it's worth the complexity given that
> PREEMPT_RT tries very hard to avoid disabling IRQs...
> 
>> Or is the irqs_disabled() condition rare enough so we don't care?
> 
> Given that most users don't call kfree_rcu() under raw spinlock or
> IRQs-disabled section on PREEMPT_RT, I think it's okay to keep it as is
> (it's not making things worse, at least) and wait for call_rcu_nolock()?

Sounds good.

> On a side note, I don't have much idea on what needs to call kfree_rcu()
> under a raw spinlock, other than set_cpus_allowed_force(), which should
> really be using kfree_nolock() instead of kfree_rcu() once we support
> kmalloc() -> kfree_nolock():

Looks like the case. Well if the fallback path of kfree_nolock() that is
irq_work_queue() is indeed safe here.

>> 	/*
>> 	 * 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);
> 
> Any thoughts, RCU/RT folks?
>