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

[Vlastimil Babka (SUSE)]

On 9/2/26 12:41, Sebastian Andrzej Siewior wrote:
> On 2026-09-01 15:59:09 [+0200], Vlastimil Babka (SUSE) wrote:
>> On 9/1/26 09:33, Sebastian Andrzej Siewior wrote:
>> > On 2026-08-31 18:02:38 [+0200], Vlastimil Babka (SUSE) wrote:
>> >> This partially reverts commit 2a8bb29ec9b2 ("mm/slab: allow
>> >> kfree_rcu_sheaf() on PREEMPT_RT"). It was based on an assumption that
>> >> local_trylock() is safe on PREEMPT_RT from any context.
>> > …
>> >> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@xxxxxxxxxx>
>> > Reviewed-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>
>> > 
>> >> ---
>> >> Incidentally I have posted a RFC [1] that leads to replacing that
>> >> kfree_rcu() from set_cpus_allowed_force() but now after back from
>> >> vacation I need to check the feedback and based on this bug report I can
>> >> already see it makes the same bad assumption that trylock is fine.
>> > 
>> > free_to_pcs() has still this trylock.
>> > 
>> > What I am not so sure how good is that kfree_rcu_nolock() may allocate
>> > memory for the sheaf if there is none around.
>> 
>> Per sashiko review it's actually bad too under the pi_lock, because
>> GFP_NOWAIT means __GFP_KSWAPD_RECLAIM which can mean wakeup_kswapd() and
>> thus also need scheduler locks. And it's not a PREEMPT_RT-only issue...
> 
> \o/

More like /o\

>> > It could have a pool of X
>> > and if it runs out, it runs out and waits until the clean up process
>> > feeds the used sheafs back. There is fallback and the run out is not the
>> > usual case.
>> 
>> I'd rather not invent new pools, since there's fallback and the sheaf+barn
>> is already a pool. Could be enough to make sure the allocation attempt is
>> safe, i.e. use only __GFP_NOWARN.
> 
> So we avoid the allocation and just add it to the sheaf+barn and this is
> it?

We don't need to avoid the allocation attempt if it's done in a safe way?
Note the new sheaf can be also served from its kmalloc slab almost
immediately, going all the way to page allocator should be very rare.
But if we stopped doing that sheaf allocation attemps completely, we could
easily end up having long bursts of all kfree_rcu() being deferred.

> Sebastian