On 07/23/14 01:16, David Rientjes wrote: > On Tue, 22 Jul 2014, Andrew Morton wrote: >>> Evaluating a macro argument only if certain configuration options >>> have been selected is confusing and error-prone. Hence always >>> evaluate the second argument of spin_lock_nested() and >>> spin_lock_nest_lock(). >>> >>> An intentional side effect of this patch is that it avoids that >>> the following warning is reported for netif_addr_lock_nested() >>> when building with CONFIG_DEBUG_LOCK_ALLOC=n and with W=1: >>> >>> ... >>> >>> --- a/include/linux/spinlock.h >>> +++ b/include/linux/spinlock.h >>> @@ -197,8 +197,10 @@ static inline void do_raw_spin_unlock(raw_spinlock_t >>> *lock) __releases(lock) >>> _raw_spin_lock_nest_lock(lock, &(nest_lock)->dep_map); \ >>> } while (0) >>> #else >>> -# define raw_spin_lock_nested(lock, subclass) >>> _raw_spin_lock(lock) >>> -# define raw_spin_lock_nest_lock(lock, nest_lock) _raw_spin_lock(lock) >>> +# define raw_spin_lock_nested(lock, subclass) \ >>> + ((void)(subclass), _raw_spin_lock(lock)) >>> +# define raw_spin_lock_nest_lock(lock, nest_lock) \ >>> + ((void)(nest_lock), _raw_spin_lock(lock)) >>> #endif >>> >> >> Did you try converting these to static inline functions? That should >> squish the warning and makes the code nicer instead of nastier... > > Not sure how that would be done since _raw_spin_lock isn't declared in > this scope. > > Taking a second look, however, I think the patch doesn't need to modify > raw_spin_lock_nest_lock() for the problem being reported and evaluating > the parameter of type struct lockdep_map * probably is meaningless. > > Bart, is it possible to just get away with the raw_spin_lock_nested() > change?
Probably ... I will post an updated version of this patch. Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
