I recently made the mistake of writing:
  foo = lockdep_dereference_protected(..., lockdep_assert_held(...));
which is clearly bogus.  If lockdep is disabled in the config this would
cause a compile failure, if it is enabled then it compiles and causes a
puzzling warning about dereferencing without the correct protection.
Wrap the macro in "do { ...  } while (0)" to also fail compile for this
when lockdep is enabled.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
 
 #define lockdep_depth(tsk)     (debug_locks ? (tsk)->lockdep_depth : 0)
 
-#define lockdep_assert_held(l) WARN_ON(debug_locks && !lockdep_is_held(l))
+#define lockdep_assert_held(l) do {                            \
+               WARN_ON(debug_locks && !lockdep_is_held(l));    \
+       } while (0)
 
 #define lockdep_recursing(tsk) ((tsk)->lockdep_recursion)