Re: [RFC PATCH 02/12] futex: Switch PI futex to use p->pi_futex_lock instead of p->pi_lock.

[Suleiman Souhlal]

Hello,

On Fri, Sep 18, 2026 at 7:07 PM K Prateek Nayak <kprateek.nayak@xxxxxxx> wrote:
>
> Hello Suleiman,
>
> On 9/18/2026 12:41 PM, Suleiman Souhlal wrote:
> > On Fri, Sep 18, 2026 at 12:38 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> >>
> >> On Thu, Sep 17, 2026 at 04:33:26AM +0000, Suleiman Souhlal wrote:
> >>> Switch PI futexes to use p->pi_futex_lock instead of p->pi_lock.
> >>>
> >>> When augmenting PING futexes with proxy execution, we get lock order
> >>> inversions, due to the lock order being p->pi_lock -> mutex->wait_lock
> >>> in the scheduler, but wait_lock -> p->pi_lock in futex code.
> >>>
> >>> So move the futex code to use a new lock, p->pi_futex_lock, to
> >>> protect p->pi_state_list and pi_state->owner.
> >>
> >> This is of course horrible. Lets not do this.
> >
> > I suppose the alternatives would be to either figure out how to
> > un-nest pi_lock from wait_lock in futex code or un-nesting the
> > blocked_on lock from pi_lock in the scheduler.
>
> So the only time we try to grab pi_lock + blocked_lock is during
> wakeup so I think doing that should be (theoretically) possible.
>
> The ttwu_runnable() handling is extremely painful unless we block
> the delayed task fully. Since we have he new p->is_blocked state,
> we can safely retain the p->blocked_on while running the task -
> it is either cleared during unlock by previosu owner or will be
> same as the lock on which the task blocked on.
>
>
> Based on John's tree at commit 06ac43db4d8e ("[ANNOTATION] ===
> Needs confirmation of functionality past this point ===") on
> proxy-exec-v31-7.2-rc4 branch:

Sorry for the slow reply and thanks for the very quick patch.

Unfortunately, it doesn't seem like this approach works in the end,
because there is still a pi_lock -> rq lock -> blocked_lock transitive
relationship, which deadlocks when trying to get the pi_lock while
holding the blocked_lock (when fixing up the pi_state owner in the
futex code). :-(

On the other hand, Peter's suggestion of moving the scheduler's use of
pi_lock to a new lock, p->sched_lock, seems to work in my testing, but
is kind of a scary change to me.

Maybe an acceptable alternative would be for the new futex to use a
new lock (similarly to what the original patch does), but keep regular
PI futexes using pi_lock, at least as long as they are still based on
rtmutexes.

Thanks,
-- Suleiman