From: Steven Rostedt <rostedt@goodmis.org>
To: john stultz <johnstul@us.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
Thomas Gleixner <tglx@linutronix.de>,
Sripathi Kodi <sripathik@in.ibm.com>,
Ulrich Drepper <drepper@gmail.com>
Subject: [PATCH RT] fix faulting bomb in futex_unlock_pi64
Date: Wed, 30 May 2007 22:52:33 -0400 [thread overview]
Message-ID: <1180579953.21781.34.camel@localhost.localdomain> (raw)
In-Reply-To: <1180572567.6126.44.camel@localhost.localdomain>
[CC'ing Uli because John forgot to with the original patch]
As John found with futex_unlock_pi (which that patch should apply nicely
to the -rt tree), the code can get screwed up with faulting in at the
cmpxchg in futex_unlock_pi code.
>From John's original email:
----
In looking into why the kernel was returning -EFAULT, I found the
following:
...
retry_locked:
/*
* To avoid races, try to do the TID -> 0 atomic transition
* again. If it succeeds then we can return without waking
* anyone else up:
*/
if (!(uval & FUTEX_OWNER_DIED)) {
pagefault_disable();
uval = futex_atomic_cmpxchg_inatomic(uaddr,
current->pid, 0);
pagefault_enable();
}
if (unlikely(uval == -EFAULT))
goto pi_faulted;
...[snip]...
pi_faulted:
/*
* We have to r/w *(int __user *)uaddr, but we can't modify it
* non-atomically. Therefore, if get_user below is not
* enough, we need to handle the fault ourselves, while
* still holding the mmap_sem.
*/
if (attempt++) {
ret = futex_handle_fault((unsigned long)uaddr, fshared,
attempt);
if (ret)
goto out_unlock;
goto retry_locked;
}
----
We see that uval is -EFAULT when jumping to pi_faulted. But when it goes
back to retry_locked, the uval is still -EFAULT. Which just happens to
have the FUTEX_OWNER_DIED bit set. So we don't do the
futex_atomic_cmpxchg_inatomic call, and go to the next conditional which
just so happens to be a check of uval for -EFAULT. And guess what? it
still is!!
Way to go John in finding this!!
But, the -rt kernel has pretty much the same code for the
futex_unlock_pi64, and it has the same bug. Hence this email.
This patch is the same fix that John posted, but simply for the
futex_unlock_pi64 that exists in the RT kernel and not the mainline.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Index: linux-2.6-rt-work/kernel/futex.c
===================================================================
--- linux-2.6-rt-work.orig/kernel/futex.c 2007-05-30 22:29:04.000000000 -0400
+++ linux-2.6-rt-work/kernel/futex.c 2007-05-30 22:32:01.000000000 -0400
@@ -3503,6 +3503,7 @@ pi_faulted:
ret = -EFAULT;
goto out_unlock;
}
+ uval = 0;
goto retry_locked;
}
next prev parent reply other threads:[~2007-05-31 2:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-31 0:49 [BUG] futex_unlock_pi() hurts my brain and may cause application deadlock john stultz
2007-05-31 1:29 ` Steven Rostedt
2007-05-31 14:53 ` Ulrich Drepper
2007-05-31 2:52 ` Steven Rostedt [this message]
2007-05-31 3:18 ` [PATCH RT] fix faulting bomb in futex_unlock_pi64 Steven Rostedt
2007-05-31 17:20 ` Ulrich Drepper
2007-05-31 14:24 ` [BUG] futex_unlock_pi() hurts my brain and may cause application deadlock Ingo Molnar
2007-05-31 14:50 ` john stultz
2007-05-31 14:55 ` Ingo Molnar
2007-05-31 16:48 ` john stultz
2007-07-31 23:53 ` [RESEND] " john stultz
2007-08-01 0:00 ` Steven Rostedt
2007-08-01 1:41 ` David Miller
2007-08-06 7:20 ` 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=1180579953.21781.34.camel@localhost.localdomain \
--to=rostedt@goodmis.org \
--cc=drepper@gmail.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sripathik@in.ibm.com \
--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;
as well as URLs for NNTP newsgroup(s).