Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [PATCH v3 7/7] locking/rtmutex: Acquire the hb lock via trylock after wait-proxylock. | Date | Fri, 15 Sep 2023 20:59:44 +0200 |
| |
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@infradead.org> > /* > * 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@linutronix.de>
| |