Re: [RFC PATCH v2 0/3] locking, mm: Add atomic allocator trylocks on RT

[Sebastian Andrzej Siewior]

On 2026-10-05 09:06:22 [+0200], Karl Mehltretter wrote:
> On PREEMPT_RT, a BPF task-storage program attached to sched_waking
> can deadlock when kmalloc_nolock() obtains an rtmutex-backed allocator
> spinlock while try_to_wake_up() holds p->pi_lock. Releasing the allocator
> lock can enter priority-inheritance or wakeup code and re-enter scheduler
> locking.

What is it that you try to achieve and why. Why is !PREEMPT_RT not
affected? Half of the problems origin from PI-boosst.
Why has the nolock an rmutex-backed allocator.

can_spin_trylock() skips hardirq and NMI. There is a trylock on the
local_lock_t.
Why do we have this mess and couldn't we avoid having it?

I looked at the patches and there something about hardirq-atomic waiter.
Wen don't have this. I don't think we want.

Sebastian