Re: [RFC 06/10] Reclaim memory from blocked kernel stacks

[Sebastian Andrzej Siewior]

On 2026-08-31 16:03:38 [+0200], Vlastimil Babka (SUSE) wrote:
> On 8/31/26 09:36, Sebastian Andrzej Siewior wrote:
> > On 2026-08-29 15:49:22 [+0100], Matthew Wilcox wrote:
> >> On Sat, Aug 29, 2026 at 10:49:01AM +0200, Peter Zijlstra wrote:
> >> > > On PREEMPT_RT, it is necessary to skip the call to
> >> > > alloc_pages_nolock_noprof() from under pi_lock, since with that
> >> > > configuration spin_trylock can end up needing to take pi_lock. But at
> >> > > least on !PREEMPT_RT, there is no risk of deadlock.
> >> > 
> >> > Yeah, which puts the lie to that horrific hack Alexei did. We should
> >> > probably teach lockdep about spin_trylock() not being safe and see the
> >> > house of cards crumble.
> 
> Is it already happening then?
> 
> https://lore.kernel.org/all/20260831053846.107974-1-ngocthang2710.1999@xxxxxxxxx/

here I would strip kfree_rcu_sheaf() from the kfree_rcu().

> >> Why is spin_trylock() unsafe on PREEMPT_RT?  It's not intuitive since
> >> one can mutex_trylock() in interrupt context or under spinlock.
> > 
> > no, you shouldn't do mutex_trylock() in IRQ. There was something, I
> > don't remember but that is the reason people use semaphores because it
> > is okay to do down_trylock() in IRQ. It might be unlock path. 
> 
> Is it what this comment (recently moved to can_spin_trylock()) explains?
> 
>         /*
>          * In PREEMPT_RT spin_trylock() will call raw_spin_lock() which is
>          * unsafe in NMI. If spin_trylock() is called from hard IRQ the current
>          * task may be waiting for one rt_spin_lock, but rt_spin_trylock() will
>          * mark the task as the owner of another rt_spin_lock which will
>          * confuse PI logic, so return immediately if called from hard IRQ or
>          * NMI.
>          *
>          * Note, irqs_disabled() case is ok. spin_trylock() can be called
>          * from raw_spin_lock_irqsave region.
>          */
>         if (IS_ENABLED(CONFIG_PREEMPT_RT) && (in_nmi() || in_hardirq()))           
>                 return false;
> 
> Of course checking for being under raw_spinlock_t can't be added like this,
> hm.

Yes.

Sebastian