Re: [PATCH v3 7/7] locking/rtmutex: Acquire the hb lock via trylock after wait-proxylock.

From: Thomas Gleixner
Date: Fri Sep 15 2023 - 15:00:47 EST


On Fri, Sep 15 2023 at 17:19, Peter Zijlstra wrote:
> On Fri, Sep 15, 2023 at 02:58:35PM +0200, Thomas Gleixner wrote:
> *However* the case at hand is where a waiter is leaving, in this case the race
> means a waiter that is going away is not observed -- which is harmless,
> provided this race is explicitly handled.
>
> This is a somewhat dangerous proposition because the converse race is not
> observing a new waiter, which must absolutely not happen. But since the race is
> valid this cannot be asserted.

Correct. But adding a new waiter requires to hold hb::lock which _IS_
held by the unlocking code when it deals with the outgoing race.

So I'm not too worried about it.

> Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
> /*
> * If we failed to acquire the lock (deadlock/signal/timeout), we must
> - * first acquire the hb->lock before removing the lock from the
> - * rt_mutex waitqueue, such that we can keep the hb and rt_mutex wait
> - * lists consistent.
> + * must unwind the above, however we canont lock hb->lock because
> + * rt_mutex already has a waiter enqueued and hb->lock can itself try
> + * and enqueue an rt_waiter through rtlock.
> + *
> + * Doing the cleanup without holding hb->lock can cause inconsistent
> + * state between hb and pi_state, but only in the direction of not
> + * seeing a waiter that is leaving.
> + *
> + * See futex_unlock_pi(), it deals with this inconsistency.
> + *
> + * There be dragons here, since we must deal with the inconsistency on
> + * the way out (here), it is impossible to detect/warn about the race
> + * the other way around (missing an incoming waiter).
> *
> - * In particular; it is important that futex_unlock_pi() can not
> - * observe this inconsistency.
> + * What could possibly go wrong...

If some code in the future tries to enqueue a waiter w/o holding
hb::lock then this corner case will be the least of our worries. There
are tons of other things which will insta go south.

Reviewed-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>