[PATCH 0/2] [GIT PULL] futex: Fix WARN_ON triggering on UP

[PATCH 0/2] [GIT PULL] futex: Fix WARN_ON triggering on UP

[Steven Rostedt]

Thomas,

Please pull the rt patches from:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-rt.git

    branch: tip/futex/devel


Steven Rostedt (2):
      WARN_ON_SMP(): Allow use in if statements on UP
      futex: Fix WARN_ON() test for UP

----
 include/asm-generic/bug.h |   28 +++++++++++++++++++++++++++-
 kernel/futex.c            |    4 ++--
 2 files changed, 29 insertions(+), 3 deletions(-)

[PATCH 1/2] WARN_ON_SMP(): Allow use in if statements on UP

[Steven Rostedt]

[-- Attachment #1: 0001-WARN_ON_SMP-Allow-use-in-if-statements-on-UP.patch --]
[-- Type: text/plain, Size: 1737 bytes --]

From: Steven Rostedt <srostedt@redhat.com>

Both WARN_ON() and WARN_ON_SMP() should be able to be used in
an if statement.

	if (WARN_ON_SMP(foo)) { ... }

Because WARN_ON_SMP() is defined as a do { } while (0) on UP,
it can not be used this way.

Convert it to the same form that WARN_ON() is, even when
CONFIG_SMP is off.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
 include/asm-generic/bug.h |   28 +++++++++++++++++++++++++++-
 1 files changed, 27 insertions(+), 1 deletions(-)

diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index c2c9ba0..ac2f48a 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -165,10 +165,36 @@ extern void warn_slowpath_null(const char *file, const int line);
 #define WARN_ON_RATELIMIT(condition, state)			\
 		WARN_ON((condition) && __ratelimit(state))
 
+/*
+ * WARN_ON_SMP() is for cases that the warning is either
+ * meaningless for !SMP or may even cause failures.
+ * This is usually used for cases that we have
+ * WARN_ON(!spin_is_locked(&lock)) checks, as spin_is_locked()
+ * returns 0 for uniprocessor settings.
+ * It can be also be used with values that are only defined
+ * on SMP:
+ *
+ * struct foo {
+ *  [...]
+ * #ifdef CONFIG_SMP
+ *	int bar;
+ * #endif
+ * };
+ *
+ * void func(struct foo *zoot)
+ * {
+ *	WARN_ON_SMP(!zoot->bar);
+ *
+ * For CONFIG_SMP, WARN_ON_SMP() should act the same as WARN_ON(),
+ * and should be a nop and return false for uniprocessor.
+ *
+ * if (WARN_ON_SMP(x)) returns true only when CONFIG_SMP is set
+ * and x is true.
+ */
 #ifdef CONFIG_SMP
 # define WARN_ON_SMP(x)			WARN_ON(x)
 #else
-# define WARN_ON_SMP(x)			do { } while (0)
+# define WARN_ON_SMP(x)			({0;})
 #endif
 
 #endif
-- 
1.7.2.3

Re: [PATCH 1/2] WARN_ON_SMP(): Allow use in if statements on UP

[Darren Hart]

On 03/17/2011 12:21 PM, Steven Rostedt wrote:
> From: Steven Rostedt<srostedt@redhat.com>
>
> Both WARN_ON() and WARN_ON_SMP() should be able to be used in
> an if statement.
>
> 	if (WARN_ON_SMP(foo)) { ... }
>
> Because WARN_ON_SMP() is defined as a do { } while (0) on UP,
> it can not be used this way.
>
> Convert it to the same form that WARN_ON() is, even when
> CONFIG_SMP is off.
>
> Signed-off-by: Steven Rostedt<rostedt@goodmis.org>
> ---
>   include/asm-generic/bug.h |   28 +++++++++++++++++++++++++++-
>   1 files changed, 27 insertions(+), 1 deletions(-)
>
> diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
> index c2c9ba0..ac2f48a 100644
> --- a/include/asm-generic/bug.h
> +++ b/include/asm-generic/bug.h
> @@ -165,10 +165,36 @@ extern void warn_slowpath_null(const char *file, const int line);
>   #define WARN_ON_RATELIMIT(condition, state)			\
>   		WARN_ON((condition)&&  __ratelimit(state))
>
> +/*
> + * WARN_ON_SMP() is for cases that the warning is either
> + * meaningless for !SMP or may even cause failures.
> + * This is usually used for cases that we have
> + * WARN_ON(!spin_is_locked(&lock)) checks, as spin_is_locked()
> + * returns 0 for uniprocessor settings.
> + * It can be also be used with values that are only defined

Typo: can be also be

--
Darren

> + * on SMP:
> + *
> + * struct foo {
> + *  [...]
> + * #ifdef CONFIG_SMP
> + *	int bar;
> + * #endif
> + * };
> + *
> + * void func(struct foo *zoot)
> + * {
> + *	WARN_ON_SMP(!zoot->bar);
> + *
> + * For CONFIG_SMP, WARN_ON_SMP() should act the same as WARN_ON(),
> + * and should be a nop and return false for uniprocessor.
> + *
> + * if (WARN_ON_SMP(x)) returns true only when CONFIG_SMP is set
> + * and x is true.
> + */
>   #ifdef CONFIG_SMP
>   # define WARN_ON_SMP(x)			WARN_ON(x)
>   #else
> -# define WARN_ON_SMP(x)			do { } while (0)
> +# define WARN_ON_SMP(x)			({0;})
>   #endif
>
>   #endif
> -- 1.7.2.3

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: [PATCH 1/2] WARN_ON_SMP(): Allow use in if statements on UP

[Peter Zijlstra]

On Thu, 2011-03-17 at 15:21 -0400, Steven Rostedt wrote:
> From: Steven Rostedt <srostedt@redhat.com>
> 
> Both WARN_ON() and WARN_ON_SMP() should be able to be used in
> an if statement.
> 
>         if (WARN_ON_SMP(foo)) { ... }
> 
> Because WARN_ON_SMP() is defined as a do { } while (0) on UP,
> it can not be used this way.
> 
> Convert it to the same form that WARN_ON() is, even when
> CONFIG_SMP is off.
> 
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> 

Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>

[tip:core/urgent] WARN_ON_SMP(): Allow use in if() statements on UP

[tip-bot for Steven Rostedt]

Commit-ID:  2092e6be82ec71ecbf5a8ceeef004bbcbdb78812
Gitweb:     http://git.kernel.org/tip/2092e6be82ec71ecbf5a8ceeef004bbcbdb78812
Author:     Steven Rostedt <srostedt@redhat.com>
AuthorDate: Thu, 17 Mar 2011 15:21:06 -0400
Committer:  Ingo Molnar <mingo@elte.hu>
CommitDate: Fri, 25 Mar 2011 11:32:09 +0100

WARN_ON_SMP(): Allow use in if() statements on UP

Both WARN_ON() and WARN_ON_SMP() should be able to be used in
an if statement.

	if (WARN_ON_SMP(foo)) { ... }

Because WARN_ON_SMP() is defined as a do { } while (0) on UP,
it can not be used this way.

Convert it to the same form that WARN_ON() is, even when
CONFIG_SMP is off.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
LKML-Reference: <20110317192208.444147791@goodmis.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 include/asm-generic/bug.h |   28 +++++++++++++++++++++++++++-
 1 files changed, 27 insertions(+), 1 deletions(-)

diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index c2c9ba0..f2d2faf 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -165,10 +165,36 @@ extern void warn_slowpath_null(const char *file, const int line);
 #define WARN_ON_RATELIMIT(condition, state)			\
 		WARN_ON((condition) && __ratelimit(state))
 
+/*
+ * WARN_ON_SMP() is for cases that the warning is either
+ * meaningless for !SMP or may even cause failures.
+ * This is usually used for cases that we have
+ * WARN_ON(!spin_is_locked(&lock)) checks, as spin_is_locked()
+ * returns 0 for uniprocessor settings.
+ * It can also be used with values that are only defined
+ * on SMP:
+ *
+ * struct foo {
+ *  [...]
+ * #ifdef CONFIG_SMP
+ *	int bar;
+ * #endif
+ * };
+ *
+ * void func(struct foo *zoot)
+ * {
+ *	WARN_ON_SMP(!zoot->bar);
+ *
+ * For CONFIG_SMP, WARN_ON_SMP() should act the same as WARN_ON(),
+ * and should be a nop and return false for uniprocessor.
+ *
+ * if (WARN_ON_SMP(x)) returns true only when CONFIG_SMP is set
+ * and x is true.
+ */
 #ifdef CONFIG_SMP
 # define WARN_ON_SMP(x)			WARN_ON(x)
 #else
-# define WARN_ON_SMP(x)			do { } while (0)
+# define WARN_ON_SMP(x)			({0;})
 #endif
 
 #endif

Re: [tip:core/urgent] WARN_ON_SMP(): Allow use in if() statements on UP

[Linus Torvalds]

On Fri, Mar 25, 2011 at 3:48 AM, tip-bot for Steven Rostedt
<srostedt@redhat.com> wrote:
> -# define WARN_ON_SMP(x)                        do { } while (0)
> +# define WARN_ON_SMP(x)                        ({0;})

That's a VERY odd way of writing "0".

Am I missing something subtle?

                        Linus

Re: [tip:core/urgent] WARN_ON_SMP(): Allow use in if() statements on UP

[Steven Rostedt]

On Fri, 2011-03-25 at 09:45 -0700, Linus Torvalds wrote:
> On Fri, Mar 25, 2011 at 3:48 AM, tip-bot for Steven Rostedt
> <srostedt@redhat.com> wrote:
> > -# define WARN_ON_SMP(x)                        do { } while (0)
> > +# define WARN_ON_SMP(x)                        ({0;})
> 
> That's a VERY odd way of writing "0".
> 
> Am I missing something subtle?

I thought about using "0", but when WARN_ON_SMP() is used outside of an
if statement, it turns into:

	0;

Which seems strange to me. Thus the ({0;}) was basically a way to state
that this is also a function and not just a 0 value.

Also, a quick test shows that

	0;

gives the warning:

	"warning: statement with no effect"

-- Steve

Re: [tip:core/urgent] WARN_ON_SMP(): Allow use in if() statements on UP

[Steven Rostedt]

On Fri, 2011-03-25 at 14:16 -0400, Steven Rostedt wrote:

> Also, a quick test shows that
> 
> 	0;
> 
> gives the warning:
> 
> 	"warning: statement with no effect"

Would you like me to add a comment that states:

	/*
	 * Use ({0;}) as just "0" will cause gcc to output:
	 *   warning: statement with no effect
	 */

-- Steve

Re: [tip:core/urgent] WARN_ON_SMP(): Allow use in if() statements on UP

[Alexey Dobriyan]

On Fri, Mar 25, 2011 at 02:19:23PM -0400, Steven Rostedt wrote:
> On Fri, 2011-03-25 at 14:16 -0400, Steven Rostedt wrote:
> 
> > Also, a quick test shows that
> > 
> > 	0;
> > 
> > gives the warning:
> > 
> > 	"warning: statement with no effect"
> 
> Would you like me to add a comment that states:
> 
> 	/*
> 	 * Use ({0;}) as just "0" will cause gcc to output:
> 	 *   warning: statement with no effect
> 	 */

Try ((void)0)

Re: [tip:core/urgent] WARN_ON_SMP(): Allow use in if() statements on UP

[Steven Rostedt]

On Fri, 2011-03-25 at 21:31 +0200, Alexey Dobriyan wrote:

> Try ((void)0)

But then if ((void)0) wont work.

-- Steve

Re: [tip:core/urgent] WARN_ON_SMP(): Allow use in if() statements on UP

[Steven Rostedt]

On Fri, 2011-03-25 at 21:31 +0200, Alexey Dobriyan wrote:

> > Would you like me to add a comment that states:
> > 
> > 	/*
> > 	 * Use ({0;}) as just "0" will cause gcc to output:
> > 	 *   warning: statement with no effect
> > 	 */
> 
> Try ((void)0)

Maybe I should update the comment to stop further confusion:

	/*
	 * Use ({0;}) as it works nicely in both an if statement and
	 * as a stand alone line statement.
	 *   "0;" causes "warning: statement with no effect"
	 *   ((void)0) does not work in an if () condition.
	 */

-- Steve

Re: [tip:core/urgent] WARN_ON_SMP(): Allow use in if() statements on UP

[Alexey Dobriyan]

On Fri, Mar 25, 2011 at 03:40:34PM -0400, Steven Rostedt wrote:
> On Fri, 2011-03-25 at 21:31 +0200, Alexey Dobriyan wrote:
> 
> > > Would you like me to add a comment that states:
> > > 
> > > 	/*
> > > 	 * Use ({0;}) as just "0" will cause gcc to output:
> > > 	 *   warning: statement with no effect
> > > 	 */
> > 
> > Try ((void)0)
> 
> Maybe I should update the comment to stop further confusion:

Ah!

I always thought if (WARN_ON(x)) is confusing and should be banned.

Re: [tip:core/urgent] WARN_ON_SMP(): Allow use in if() statements on UP

[Steven Rostedt]

On Fri, 2011-03-25 at 21:47 +0200, Alexey Dobriyan wrote:

> I always thought if (WARN_ON(x)) is confusing and should be banned.

I think that's the preferred method (I use it all the time).

	if (WARN_ON(blah))
		goto fail;

Better than:

	if (x) {
		WARN_ON(1);
		goto fail;
	}

-- Steve

Re: [tip:core/urgent] WARN_ON_SMP(): Allow use in if() statements on UP

[Ingo Molnar]

* Alexey Dobriyan <adobriyan@gmail.com> wrote:

> On Fri, Mar 25, 2011 at 03:40:34PM -0400, Steven Rostedt wrote:
> > On Fri, 2011-03-25 at 21:31 +0200, Alexey Dobriyan wrote:
> > 
> > > > Would you like me to add a comment that states:
> > > > 
> > > > 	/*
> > > > 	 * Use ({0;}) as just "0" will cause gcc to output:
> > > > 	 *   warning: statement with no effect
> > > > 	 */
> > > 
> > > Try ((void)0)
> > 
> > Maybe I should update the comment to stop further confusion:
> 
> Ah!
> 
> I always thought if (WARN_ON(x)) is confusing and should be banned.

I'd encourage you to read kernel/lockdep.c one day:

		return DEBUG_LOCKS_WARN_ON(1);
		DEBUG_LOCKS_WARN_ON(1);
	if (DEBUG_LOCKS_WARN_ON(class->subclass != subclass))
	if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
		if (DEBUG_LOCKS_WARN_ON(id >= MAX_LOCKDEP_KEYS))
	if (DEBUG_LOCKS_WARN_ON(unlikely(early_boot_irqs_disabled)))
	if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
	if (DEBUG_LOCKS_WARN_ON(current->hardirq_context))
	if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
	if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
	if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
		DEBUG_LOCKS_WARN_ON(!softirq_count());
	if (DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)))
	if (DEBUG_LOCKS_WARN_ON(!name)) {
	if (DEBUG_LOCKS_WARN_ON(!key))
		DEBUG_LOCKS_WARN_ON(1);
	if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
	if (DEBUG_LOCKS_WARN_ON(depth >= MAX_LOCK_DEPTH))
	if (DEBUG_LOCKS_WARN_ON(!class))
	if (DEBUG_LOCKS_WARN_ON(id >= MAX_LOCKDEP_KEYS))
		if (DEBUG_LOCKS_WARN_ON(chain_key != 0))
	if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
		if (DEBUG_LOCKS_WARN_ON(!class))
		if (DEBUG_LOCKS_WARN_ON(!hlock->nest_lock))
	if (DEBUG_LOCKS_WARN_ON(!depth))
	if (DEBUG_LOCKS_WARN_ON(curr->lockdep_depth != depth))
	if (DEBUG_LOCKS_WARN_ON(!depth))
	if (DEBUG_LOCKS_WARN_ON(curr->lockdep_depth != depth - 1))
	if (DEBUG_LOCKS_WARN_ON(!depth && (hlock->prev_chain_key != 0)))
		if (DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled)) {
		if (DEBUG_LOCKS_WARN_ON(!current->hardirqs_enabled)) {
			DEBUG_LOCKS_WARN_ON(current->softirqs_enabled);
			DEBUG_LOCKS_WARN_ON(!current->softirqs_enabled);
	if (DEBUG_LOCKS_WARN_ON(!depth))
	if (DEBUG_LOCKS_WARN_ON(!depth))

These conditional warnings made the flow a lot clearer and simpler - while 
still giving us a very robust lockdep machinery that wont crash no matter what 
kind of anomaly happens.

But yes, i can imagine such constructs being misused as well when mixed into 
real, non-debug functionality. As usual, it's just a tool, with good and evil 
uses as well - so your 'it should be banned' position is too extreme IMHO.

Thanks,

	Ingo

[PATCH 2/2] futex: Fix WARN_ON() test for UP

[Steven Rostedt]

[-- Attachment #1: 0002-futex-Fix-WARN_ON-test-for-UP.patch --]
[-- Type: text/plain, Size: 1077 bytes --]

From: Steven Rostedt <srostedt@redhat.com>

An update of the futex code had a

	WARN_ON(!spin_is_locked(q->lock_ptr))

But on UP, spin_is_locked() is always false, and will
trigger this warning, and even worse, it will exit the function
without doing the necessary work.

Converting this to a WARN_ON_SMP() fixes the problem.

Reported-by: Richard Weinberger <richard@nod.at>
Tested-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
 kernel/futex.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index 9fe9131..850d00b 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -785,8 +785,8 @@ static void __unqueue_futex(struct futex_q *q)
 {
 	struct futex_hash_bucket *hb;
 
-	if (WARN_ON(!q->lock_ptr || !spin_is_locked(q->lock_ptr)
-			|| plist_node_empty(&q->list)))
+	if (WARN_ON_SMP(!q->lock_ptr || !spin_is_locked(q->lock_ptr))
+	    || WARN_ON(plist_node_empty(&q->list)))
 		return;
 
 	hb = container_of(q->lock_ptr, struct futex_hash_bucket, lock);
-- 
1.7.2.3

Re: [PATCH 2/2] futex: Fix WARN_ON() test for UP

[Darren Hart]

On 03/17/2011 12:21 PM, Steven Rostedt wrote:
> From: Steven Rostedt<srostedt@redhat.com>
>
> An update of the futex code had a
>
> 	WARN_ON(!spin_is_locked(q->lock_ptr))
>
> But on UP, spin_is_locked() is always false, and will
> trigger this warning, and even worse, it will exit the function
> without doing the necessary work.
>
> Converting this to a WARN_ON_SMP() fixes the problem.
>
> Reported-by: Richard Weinberger<richard@nod.at>
> Tested-by: Richard Weinberger<richard@nod.at>
> Signed-off-by: Steven Rostedt<rostedt@goodmis.org>

Acked-by: Darren Hart <dvhart@linux.intel.com>


> ---
>   kernel/futex.c |    4 ++--
>   1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/futex.c b/kernel/futex.c
> index 9fe9131..850d00b 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -785,8 +785,8 @@ static void __unqueue_futex(struct futex_q *q)
>   {
>   	struct futex_hash_bucket *hb;
>
> -	if (WARN_ON(!q->lock_ptr || !spin_is_locked(q->lock_ptr)
> -			|| plist_node_empty(&q->list)))
> +	if (WARN_ON_SMP(!q->lock_ptr || !spin_is_locked(q->lock_ptr))
> +	    || WARN_ON(plist_node_empty(&q->list)))
>   		return;
>
>   	hb = container_of(q->lock_ptr, struct futex_hash_bucket, lock);
> -- 1.7.2.3 -- To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo@vger.kernel.org More
> majordomo info at http://vger.kernel.org/majordomo-info.html Please read
> the FAQ at http://www.tux.org/lkml/

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: [PATCH 2/2] futex: Fix WARN_ON() test for UP

[Peter Zijlstra]

On Thu, 2011-03-17 at 15:21 -0400, Steven Rostedt wrote:
> From: Steven Rostedt <srostedt@redhat.com>
> 
> An update of the futex code had a
> 
>         WARN_ON(!spin_is_locked(q->lock_ptr))
> 
> But on UP, spin_is_locked() is always false, and will
> trigger this warning, and even worse, it will exit the function
> without doing the necessary work.
> 
> Converting this to a WARN_ON_SMP() fixes the problem.
> 
> Reported-by: Richard Weinberger <richard@nod.at>
> Tested-by: Richard Weinberger <richard@nod.at>
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> 

Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>

[tip:core/urgent] futex: Fix WARN_ON() test for UP

[tip-bot for Steven Rostedt]

Commit-ID:  29096202176ceaa5016a17ea2dd1aea19a4e90e2
Gitweb:     http://git.kernel.org/tip/29096202176ceaa5016a17ea2dd1aea19a4e90e2
Author:     Steven Rostedt <srostedt@redhat.com>
AuthorDate: Thu, 17 Mar 2011 15:21:07 -0400
Committer:  Ingo Molnar <mingo@elte.hu>
CommitDate: Fri, 25 Mar 2011 11:32:11 +0100

futex: Fix WARN_ON() test for UP

An update of the futex code had a

	WARN_ON(!spin_is_locked(q->lock_ptr))

But on UP, spin_is_locked() is always false, and will
trigger this warning, and even worse, it will exit the function
without doing the necessary work.

Converting this to a WARN_ON_SMP() fixes the problem.

Reported-by: Richard Weinberger <richard@nod.at>
Tested-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <20110317192208.682654502@goodmis.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 kernel/futex.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index bda4157..823aae3 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -782,8 +782,8 @@ static void __unqueue_futex(struct futex_q *q)
 {
 	struct futex_hash_bucket *hb;
 
-	if (WARN_ON(!q->lock_ptr || !spin_is_locked(q->lock_ptr)
-			|| plist_node_empty(&q->list)))
+	if (WARN_ON_SMP(!q->lock_ptr || !spin_is_locked(q->lock_ptr))
+	    || WARN_ON(plist_node_empty(&q->list)))
 		return;
 
 	hb = container_of(q->lock_ptr, struct futex_hash_bucket, lock);

Re: [PATCH 0/2] [GIT PULL] futex: Fix WARN_ON triggering on UP

[Steven Rostedt]

On Thu, 2011-03-17 at 15:21 -0400, Steven Rostedt wrote:
> Thomas,
> 
> Please pull the rt patches from:

Oops, sorry this is for mainline not -rt, I used the wrong boiler plate.

-- Steve

> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-rt.git
> 
>     branch: tip/futex/devel
> 
> 
> Steven Rostedt (2):
>       WARN_ON_SMP(): Allow use in if statements on UP
>       futex: Fix WARN_ON() test for UP
> 
> ----
>  include/asm-generic/bug.h |   28 +++++++++++++++++++++++++++-
>  kernel/futex.c            |    4 ++--
>  2 files changed, 29 insertions(+), 3 deletions(-)