Messages in this thread | | | Date | Thu, 9 Sep 2021 14:45:24 +0100 | From | Will Deacon <> | Subject | Re: [PATCH 1/4] sched/wakeup: Strengthen current_save_and_set_rtlock_wait_state() |
| |
On Thu, Sep 09, 2021 at 12:59:16PM +0200, Peter Zijlstra wrote: > While looking at current_save_and_set_rtlock_wait_state() I'm thinking > it really ought to use smp_store_mb(), because something like: > > current_save_and_set_rtlock_wait_state(); > for (;;) { > if (try_lock()) > break; > > raw_spin_unlock_irq(&lock->wait_lock); > schedule(); > raw_spin_lock_irq(&lock->wait_lock); > > set_current_state(TASK_RTLOCK_WAIT); > } > current_restore_rtlock_saved_state(); > > which is the advertised usage in the comment, is actually broken, > since trylock() will only need a load-acquire in general and that > could be re-ordered against the state store, which could lead to a > missed wakeup -> BAD (tm).
Why doesn't the UNLOCK of pi_lock in current_save_and_set_rtlock_wait_state() order the state change before the successful try_lock? I'm just struggling to envisage how this actually goes wrong.
Will
| |