From: john stultz <johnstul@us.ibm.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
mingo@redhat.com, lkml <linux-kernel@vger.kernel.org>
Subject: [RFC][-rt PATCH] Try to safely error out when mixing pi/non-pi futex operations on the same futex.
Date: Wed, 17 May 2006 14:08:49 -0700 [thread overview]
Message-ID: <1147900129.9363.7.camel@localhost.localdomain> (raw)
Ingo,
We've been seeing some oopses because there are waiters on pi futexes
that do not have pi_states. This seems to be because they were used w/
futex_wait in one path and futex_lock_pi in another.
I'm told this shouldn't ever happen, but if it did, the kernel should
safely error out, instead of oopsing or never releasing a lock.
Not sure if this is a solid fix (it does build and boot), but hopefully
it will stir up some discussion.
thanks
-john
Try to handle odd cases where a futex is used w/ both the pi and non-pi methods.
Signed-off-by: John Stultz <johnstul@us.ibm.com>
Index: futex-test/kernel/futex.c
===================================================================
--- futex-test.orig/kernel/futex.c 2006-05-17 13:44:41.000000000 -0500
+++ futex-test/kernel/futex.c 2006-05-17 15:48:45.000000000 -0500
@@ -472,11 +472,17 @@
list_for_each_entry_safe(this, next, head, list) {
if (match_futex (&this->key, &me->key)) {
- /*
- * Another waiter already exists - bump up
- * the refcount and return its pi_state:
- */
+ /* Another waiter already exists */
pi_state = this->pi_state;
+
+ /* make sure its a PI waiter: */
+ if (!pi_state) {
+ printk("BUG: %s/%d: Mixing pi and non pi"
+ " futexes!\n", current->comm,
+ current->pid);
+ return -EINVAL;
+ }
+ /* bump up the refcount and return its pi_state: */
atomic_inc(&pi_state->refcount);
me->pi_state = pi_state;
pr_debug("Waiter found: %d\n",
@@ -638,8 +644,14 @@
list_for_each_entry_safe(this, next, head, list) {
if (match_futex (&this->key, &key)) {
- if (this->pi_state)
- return -EINVAL;
+ /* XXX - this might cause odd behavior
+ * as we may have already woken some futexes
+ * before we return -EINVAL -johnstul@us.ibm.com
+ */
+ if (this->pi_state) {
+ ret = -EINVAL;
+ break;
+ }
wake_futex(this);
if (++ret >= nr_wake)
break;
@@ -1200,6 +1212,9 @@
ret = lookup_pi_state(uval, hb, &q);
if (unlikely(ret)) {
+ /* Handle pi/non-pi mixups: */
+ if (ret == -EINVAL)
+ goto out_unlock_release_sem;
/*
* There were no waiters and the owner task lookup
* failed. When the OWNER_DIED bit is set, then we
next reply other threads:[~2006-05-17 21:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-17 21:08 john stultz [this message]
2006-05-18 7:58 ` Ingo Molnar
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=1147900129.9363.7.camel@localhost.localdomain \
--to=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.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
all inboxes | Powered by JetHome®