All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: Dave Jones <davej@redhat.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Darren Hart <darren@dvhart.com>
Subject: Re: futex_wait_setup sleeping while atomic bug.
Date: Fri, 12 Sep 2014 10:12:12 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.10.1409121011320.4178@nanos> (raw)
In-Reply-To: <1410479618.14217.4.camel@linux-t7sj.site>

On Thu, 11 Sep 2014, Davidlohr Bueso wrote:

> On Thu, 2014-09-11 at 23:52 +0200, Thomas Gleixner wrote:
> > From: Thomas Gleixner <tglx@linutronix.de>
> > Date: Thu, 11 Sep 2014 23:44:35 +0200
> > Subject: futex: Unlock hb->lock in futex_wait_requeue_pi() error path
> 
> That's the second time we are bitten by bugs in when requeing, now pi.
> We need to reconsider some of our testing tools to stress these paths
> better, imo.

Testing tools are nice. What we really need is more competent eyes
looking at that code ...
 
> > futex_wait_requeue_pi() calls futex_wait_setup(). If
> > futex_wait_setup() succeeds it returns with hb->lock held and
> > preemption disabled. Now the sanity check after this does:
> > 
> >         if (match_futex(&q.key, &key2)) {
> > 	   	ret = -EINVAL;
> > 		goto out_put_keys;
> > 	}
> > 
> > which releases the keys but does not release hb->lock. So we happily
> > return to user space with hb->lock held and therefor preemption
> > disabled.
> > 
> > Unlock hb->lock before taking the exit route.
> > 
> > Reported-by: Dave "Trinity" Jones <davej@redhat.com>
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> 
> Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
> 
> 
> 

  parent reply	other threads:[~2014-09-12  8:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-11 15:10 futex_wait_setup sleeping while atomic bug Dave Jones
2014-09-11 21:52 ` Thomas Gleixner
2014-09-11 22:16   ` Darren Hart
2014-09-11 23:53   ` Davidlohr Bueso
2014-09-12  0:07     ` Darren Hart
2014-09-12  8:12     ` Thomas Gleixner [this message]
2014-09-12 20:10   ` [tip:locking/urgent] futex: Unlock hb-> lock in futex_wait_requeue_pi() error path tip-bot for Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.10.1409121011320.4178@nanos \
    --to=tglx@linutronix.de \
    --cc=a.p.zijlstra@chello.nl \
    --cc=darren@dvhart.com \
    --cc=dave@stgolabs.net \
    --cc=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.