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

[Vlastimil Babka (SUSE)]

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/

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

> Sebastian