On Mon, Oct 05, 2026 at 09:06:22AM +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. > > The first RFC [1] rejected every non-preemptible caller. That prevents the > deadlock, but it also rejects BPF arena allocation and faults under the > arena's ordinary raw lock. > > This RFC instead adds an atomic owner state for bounded PREEMPT_RT spinlock > trylocks. Atomic acquisition succeeds only from the completely free state.
Please don't skip discussion stage and jump into submitting a very intrusive change across locking and mm, assisted by LLM? :/ I don't think attempts to tackle this problem will make progress without discussing and getting buy-in from (PREEMPT_RT) locking folks. > A regular waiter sets HAS_WAITERS before waiting, which prevents a later > atomic owner from barging. Atomic release preserves HAS_WAITERS and does > not enter priority inheritance or wake a task. Preemption and local > interrupts remain disabled for the atomic-owner section. -- Cheers, Harry / Hyeonggon
