On Wed, Oct 07, 2026 at 07:15:29PM +0100, Harry Yoo wrote: > 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. >
Sebastian, Peter, Thomas, did you have a chance to look at the locking direction here? Thanks, Karl
