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

[Harry Yoo]

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