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

[Peter Zijlstra <peterz@infradead.org>]

On Fri, Sep 18, 2026 at 04:11:03PM +0900, Suleiman Souhlal wrote:
> On Fri, Sep 18, 2026 at 12:38 AM Peter Zijlstra <peterz@infradead.org> 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.
> Either of them seemed more involved than creating a new lock, but
> maybe I was wrong.

So the reason I reacted was because the futex_pi code is tied into
rt_mutex and it isn't at all obvious separating futex from rt_mutex
doesn't completely wreck things.

The scheduler's (ab)use of pi_lock might be simpler to separate -- it
was the last added. I basically used pi_lock because I needed a
per-task raw_spinlock and pi_lock existed and had the right nesting
properties already (rq->lock nests inside pi->lock).

Still, its been a while since I did that, so if you untangle that be
very careful.

That is, doing something like s/pi_lock/sched_lock/ on kernel/sched/
*might* just work. But separating futex from rt_mutex seems very
dangerous to me.