On Fri, 18 Jan 2013 23:31:43 +0100 Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > From: Johannes Berg <johannes.berg@xxxxxxxxx> > > 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. > > ... > > --- a/include/linux/lockdep.h > +++ b/include/linux/lockdep.h > @@ -359,7 +359,9 @@ extern void lockdep_trace_alloc(gfp_t mask); > > #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) A sane fix would be to convert lockdep_assert_held() into a static inline void C function. But, alas, much of the lockdep API is designed to work on "any type which has a field called dep_map", which was rather a silly stunt IMO. lockdep_depth() and lockdep_assert_held() may or may not evaluate their argument, and this is runtime controllable. whee. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html