From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754422AbbGQVd5 (ORCPT ); Fri, 17 Jul 2015 17:33:57 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]:35172 "EHLO e34.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752300AbbGQVdm (ORCPT ); Fri, 17 Jul 2015 17:33:42 -0400 X-Helo: d03dlp03.boulder.ibm.com X-MailFrom: paulmck@linux.vnet.ibm.com X-RcptTo: linux-next@vger.kernel.org Date: Fri, 17 Jul 2015 14:33:36 -0700 From: "Paul E. McKenney" To: Ingo Molnar Cc: Stephen Rothwell , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Peter Zijlstra , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Andy Lutomirski Subject: Re: linux-next: build failure after merge of the rcu tree Message-ID: <20150717213336.GL3717@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20150716131423.4c849184@canb.auug.org.au> <20150716035138.GQ3717@linux.vnet.ibm.com> <20150717114046.GB5396@gmail.com> <20150717173528.GH3717@linux.vnet.ibm.com> <20150717185321.GA10554@linux.vnet.ibm.com> <20150717195131.GA27792@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150717195131.GA27792@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15071721-0017-0000-0000-00000C68CD3C Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 17, 2015 at 09:51:31PM +0200, Ingo Molnar wrote: > > * Paul E. McKenney wrote: > > > And here is a prototype patch, which I intend to merge with the existing patch > > that renames rcu_lockdep_assert() to RCU_LOCKDEP_WARN(). I will also queue a > > revert of the patch below for 4.4. > > > > Thoughts? > > > > Thanx, Paul > > > > ------------------------------------------------------------------------ > > > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h > > index 41c49b12fe6d..663d6e028c3d 100644 > > --- a/include/linux/rcupdate.h > > +++ b/include/linux/rcupdate.h > > @@ -536,9 +536,29 @@ static inline int rcu_read_lock_sched_held(void) > > > > #endif /* #else #ifdef CONFIG_DEBUG_LOCK_ALLOC */ > > > > +/* Deprecate the rcu_lockdep_assert() macro. */ > > +static inline void __attribute((deprecated)) deprecate_rcu_lockdep_assert(void) > > +{ > > +} > > + > > #ifdef CONFIG_PROVE_RCU > > > > /** > > + * rcu_lockdep_assert - emit lockdep splat if specified condition not met > > + * @c: condition to check > > + * @s: informative message > > + */ > > +#define rcu_lockdep_assert(c, s) \ > > + do { \ > > + static bool __section(.data.unlikely) __warned; \ > > + deprecate_rcu_lockdep_assert(); \ > > + if (debug_lockdep_rcu_enabled() && !__warned && !(c)) { \ > > + __warned = true; \ > > + lockdep_rcu_suspicious(__FILE__, __LINE__, s); \ > > + } \ > > Btw., out of general macro paranoia I'd write such constructs as something like: > > if (!(c) && debug_lockdep_rcu_enabled() && !__warned) { \ > > I.e. always evaluate 'c' even if debugging is off. This way if the construct is > fed an expression with a side effect (bad idea!) then it still works regardless of > whether the warning triggered already or not. If you feel strongly about this, I will need to make lockdep_is_held() be defined when lockdep is disabled. Easy enough to do, just thought I should double-check. > But this construct is OK too to me, so feel free to add my: > > Reviewed-by: Ingo Molnar Thank you! Thanx, Paul