From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932104AbbJMUiS (ORCPT ); Tue, 13 Oct 2015 16:38:18 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:55136 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932067AbbJMUiR (ORCPT ); Tue, 13 Oct 2015 16:38:17 -0400 Date: Tue, 13 Oct 2015 22:38:12 +0200 From: Peter Zijlstra To: Arnd Bergmann Cc: Ingo Molnar , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Mark Brown , Liam Girdwood , akpm@linux-foundation.org Subject: Re: [PATCH] mutex: make mutex_lock_nested an inline function Message-ID: <20151013203812.GM17308@twins.programming.kicks-ass.net> References: <11282238.AHmyWliPRj@wuerfel> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11282238.AHmyWliPRj@wuerfel> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 13, 2015 at 10:30:08PM +0200, Arnd Bergmann wrote: > The second argument of the mutex_lock_nested() helper is only > evaluated if CONFIG_DEBUG_LOCK_ALLOC is set. Otherwise we > get this build warning for the new regulator_lock_supply > function: > > drivers/regulator/core.c: In function 'regulator_lock_supply': > drivers/regulator/core.c:142:6: warning: unused variable 'i' [-Wunused-variable] > > To avoid the warning, this patch changes the definition of > mutex_lock_nested() to be static inline function rather than > a macro, which tells gcc that the variable is potentially > used. > -# define mutex_lock_nested(lock, subclass) mutex_lock(lock) > +static inline void mutex_lock_nested(struct mutex *lock, unsigned int subclass) > +{ > + return mutex_lock(lock); > +} Can you verify that this results in an identical kernel? Having this a proper argument results in the compiler having to actually evaluate the expression resulting in @subclass, this might have side effects and generate code. A quick grep shows a large amount of trivial code that optimizers will still happily throw away, but it should be verified that this does not result in pointless code generation.