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

[Vlastimil Babka (SUSE)]

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

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

> I do remember RCU tried the same thing but then it got to the case where
> HEAD had to be supplied or it had to be preemptible so could wait for
> grace period and free it. I just don't remember if it had a pool pages
> to fill pointers to or allocated pages if it run out. And I am too lazy
> to look atm.

Yeah.

> Sebastian