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
