From: Darren Hart <dvhart@infradead.org>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: Thomas Gleixner <tglx@linutronix.de>,
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: Thu, 11 Sep 2014 17:07:18 -0700 [thread overview]
Message-ID: <20140912000718.GD18425@vmdeb7> (raw)
In-Reply-To: <1410479618.14217.4.camel@linux-t7sj.site>
On Thu, Sep 11, 2014 at 04:53:38PM -0700, 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.
We do, yes. Per the kselftest discussion at kernel summit, I agreed to move the
futextest testsuite into the kernel, function into kselftest and performance
into perf, then futextest can go away. From there we can look at how to improve
these tests.
Sadly, the best testing we seem to have is trinity - which does a fantastic job
at finding nasties.
If someone wanted to start having a look at migrating the futextest tests
over... I certainly wouldn't object to the help! ;-)
git://git.kernel.org/pub/scm/linux/kernel/git/dvhart/futextest.git
--
Darren Hart
Intel Open Source Technology Center
next prev parent reply other threads:[~2014-09-12 0:07 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 [this message]
2014-09-12 8:12 ` Thomas Gleixner
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=20140912000718.GD18425@vmdeb7 \
--to=dvhart@infradead.org \
--cc=a.p.zijlstra@chello.nl \
--cc=darren@dvhart.com \
--cc=dave@stgolabs.net \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox