Skip to contentSkip to conversation

futex: Fix WARN_ON trigging on UP

GIT PULL In review Steven Rostedt 2 participants 7 messages Mar 17, 2011 – Mar 24, 2011 Generic include/asm header files

lore
Share & tools
lore
#0 lore raw

Thomas,

Changes for v2:

o Added Darren's Acked-by to 2/2

o Two be's or not two be's... THAT is the question! (the answer is one be)

Please pull the futex 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(-)
#1 lore raw

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

From: Steven Rostedt <[email protected]>

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.

---
 include/asm-generic/bug.h |   28 +++++++++++++++++++++++++++-
 1 files changed, 27 insertions(+), 1 deletions(-)
include/asm-generic/bug.h +27 -1
index c2c9ba0..f2d2faf 100644
@@ -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
Signature · 1 line
1.7.2.3
#2 lore raw

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

Quoted 2 lines · Steven Rostedt

+ * WARN_ON(!spin_is_locked(&lock)) checks, as spin_is_locked()
+ * returns 0 for uniprocessor settings.

Arguably most spin_is_locked() usages should be removed in favour of something like lockdep_assert_held().

The latter only emits code then built with lockdep enabled and it checks we are indeed the owner, not some random other cpu.

#3 lore raw

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

Quoted 10 lines · Peter Zijlstra
Quoted 2 lines · Steven Rostedt

+ * WARN_ON(!spin_is_locked(&lock)) checks, as spin_is_locked()
+ * returns 0 for uniprocessor settings.

Arguably most spin_is_locked() usages should be removed in favour of something like lockdep_assert_held().

The latter only emits code then built with lockdep enabled and it checks we are indeed the owner, not some random other cpu.

Perhaps we should have lockdep_assert_held() also be in "spin_is_locked()". The warning with spin_is_locked() is still nice to have because it can trigger on production systems that might find a code path that it's not locked. lockdep is too heavy to run on production systems. But if lockdep is enabled, the spin_is_locked() should probably check ownership too.

-- Steve

#4 lore raw

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

Quoted 8 lines · Steven Rostedt
Quoted 7 lines · Peter Zijlstra
Quoted 2 lines · Steven Rostedt

+ * WARN_ON(!spin_is_locked(&lock)) checks, as spin_is_locked()
+ * returns 0 for uniprocessor settings.

Arguably most spin_is_locked() usages should be removed in favour of something like lockdep_assert_held().

Quoted 6 lines
Quoted 3 lines

The latter only emits code then built with lockdep enabled and it checks we are indeed the owner, not some random other cpu.

Perhaps we should have lockdep_assert_held() also be in "spin_is_locked()".

Can't since its got stronger requirements.

#5 lore raw

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

In reply to Peter Zijlstra
Quoted 10 lines · Peter Zijlstra
Quoted 2 lines · Steven Rostedt

+ * WARN_ON(!spin_is_locked(&lock)) checks, as spin_is_locked()
+ * returns 0 for uniprocessor settings.

Arguably most spin_is_locked() usages should be removed in favour of something like lockdep_assert_held().

The latter only emits code then built with lockdep enabled and it checks we are indeed the owner, not some random other cpu.

Without going into the issue that spin_is_locked() should go into the lockdep category, and we should restructure every user of it to use lockdep instead...

Peter, for the immediate fix (eg. this merge window), can I have your acked-by for this patch?

Thanks,

-- Steve

#6 lore raw

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

In reply to Steven Rostedt

From: Steven Rostedt <[email protected]>

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.

---
 kernel/futex.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
kernel/futex.c +2 -2
index 9fe9131..850d00b 100644
@@ -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);
Signature · 1 line
1.7.2.3