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

[Sebastian Andrzej Siewior]

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/

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