Messages in this thread | | | Date | Tue, 7 Mar 2017 18:59:57 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [PATCH -v5 12/14] futex,rt_mutex: Restructure rt_mutex_finish_proxy_lock() |
| |
On Tue, 7 Mar 2017, Peter Zijlstra wrote:
> On Tue, Mar 07, 2017 at 03:18:46PM +0100, Thomas Gleixner wrote: > > On Sat, 4 Mar 2017, Peter Zijlstra wrote: > > > +/** > > > + * rt_mutex_cleanup_proxy_lock() - Cleanup failed lock acquisition > > > + * @lock: the rt_mutex we were woken on > > > + * @waiter: the pre-initialized rt_mutex_waiter > > > + * > > > + * Clean up the failed lock acquisition as per rt_mutex_wait_proxy_lock(). > > > + * > > > + * Returns: > > > + * true - did the cleanup, we done. > > > + * false - we acquired the lock after rt_mutex_wait_proxy_lock() returned, > > > + * caller should disregards its return value. > > > > Hmm. How would that happen? Magic owner assignement to a non waiter? The > > callsite only calls here in the failed case. > > Ah, but until the remove_waiter() below, we _still_ are a waiter, and > thus can get assigned ownership. > > > > + * > > > + * Special API call for PI-futex support > > > + */ > > > +bool rt_mutex_cleanup_proxy_lock(struct rt_mutex *lock, > > > + struct rt_mutex_waiter *waiter) > > > +{ > > > + bool cleanup = false; > > > + > > > + raw_spin_lock_irq(&lock->wait_lock); > > > + /* > > > + * If we acquired the lock, no cleanup required. > > > + */ > > > + if (rt_mutex_owner(lock) != current) { > > > + remove_waiter(lock, waiter); > > See, up till this point, we still a waiter and any unlock can see us > being one.
Hmm, true. So the comments should explain that
Thanks,
tglx
| |