Messages in this thread Patch in this message |  | | Date | Sat, 19 Dec 2015 21:15:24 -0800 | From | Darren Hart <> | Subject | Re: [patch 5/5] futex: Cleanup the goto confusion in requeue_pi() |
| |
On Sat, Dec 19, 2015 at 08:07:41PM -0000, Thomas Gleixner wrote: > out_unlock: does not only drop the locks, it also drops the refcount > on the pi_state. Really intuitive. > > Move the label after the put_pi_state() call and use 'break' in the > error handling path of the requeue loop. > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > --- > kernel/futex.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > --- a/kernel/futex.c > +++ b/kernel/futex.c > @@ -1842,20 +1842,21 @@ static int futex_requeue(u32 __user *uad > */ > this->pi_state = NULL; > put_pi_state(pi_state); > - goto out_unlock; > + break; > } > } > requeue_futex(this, hb1, hb2, &key2); > drop_count++; > } > > -out_unlock: > /* > * We took an extra initial reference to the pi_state either > * in futex_proxy_trylock_atomic() or in lookup_pi_state(). We > * need to drop it here again. > */ > put_pi_state(pi_state); > + > +out_unlock: > double_unlock_hb(hb1, hb2); > wake_up_q(&wake_q); > hb_waiters_dec(hb2);
Thanks for catching the leak Thomas, sorry I missed it :-/
I thought you missed one point early on shortly after retry_private: where we goto out_unlock, but we haven't claimed the pi_state yet - so this appears to have been another unnecessary (harmless) put_pi_state call previously.
For the series:
Reviewed-by: Darren Hart <dvhart@linux.intel.com>
As a follow-on, I think it might be worthwhile to create a symmetrical get_pi_state() to the put_pi_state(), rather than handling the atomic_inc directly.
And finally, while the break; in futex_requeue works, that function is quite long and an explicit out_put_pi_state: label would make the intention clear and also avoid inadvertently breaking the implicit behavior of the break.
Thanks,
-- Darren Hart Intel Open Source Technology Center
|  |