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 <t...@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 <dvh...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
