linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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;
 	}
 



  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).