From patchwork Thu May 23 10:09:50 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Eric W. Biederman" X-Patchwork-Id: 2606011 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) by patchwork1.kernel.org (Postfix) with ESMTP id 5B9BA3FDBC for ; Thu, 23 May 2013 10:11:22 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1UfSUS-0004xo-O4; Thu, 23 May 2013 10:11:20 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1UfSUQ-0007Tf-29; Thu, 23 May 2013 10:11:18 +0000 Received: from out02.mta.xmission.com ([166.70.13.232]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1UfSUG-0007SH-G2 for linux-arm-kernel@lists.infradead.org; Thu, 23 May 2013 10:11:16 +0000 Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1UfSTH-0003xS-Na; Thu, 23 May 2013 04:10:08 -0600 Received: from c-98-207-154-105.hsd1.ca.comcast.net ([98.207.154.105] helo=eric-ThinkPad-X220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1UfSTC-0000kJ-Nn; Thu, 23 May 2013 04:10:07 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Arnd Bergmann References: <519DCBEF.3090208@asianux.com> <20130523090534.GJ18614@n2100.arm.linux.org.uk> <201305231139.38233.arnd@arndb.de> Date: Thu, 23 May 2013 03:09:50 -0700 In-Reply-To: <201305231139.38233.arnd@arndb.de> (Arnd Bergmann's message of "Thu, 23 May 2013 11:39:37 +0200") Message-ID: <878v369fdd.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 X-XM-AID: U2FsdGVkX18L2YNZK4qZk51EIeGPvRr5p2yF4vqbA2s= X-SA-Exim-Connect-IP: 98.207.154.105 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sa06.xmission.com X-Spam-Level: X-Spam-Status: No, score=-3.3 required=8.0 tests=ALL_TRUSTED,BAYES_00, DCC_CHECK_NEGATIVE, T_TM2_M_HEADER_IN_MSG, T_TooManySym_01, T_TooManySym_02, T_TooManySym_03,XMSubLong autolearn=disabled version=3.3.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: T_TM2_M_HEADER_IN_MSG * -3.0 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0059] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject * 0.0 T_TooManySym_03 6+ unique symbols in subject * 0.0 T_TooManySym_02 5+ unique symbols in subject X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Arnd Bergmann X-Spam-Relay-Country: Subject: Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it. X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 14:26:46 -0700) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130523_061108_581805_F6FCB7AD X-CRM114-Status: GOOD ( 19.01 ) X-Spam-Score: -3.0 (---) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-3.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [166.70.13.232 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -1.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Catalin Marinas , Linux-sh list , Benjamin Herrenschmidt , Chen Gang , Heiko Carstens , "paulus@samba.org" , "H. Peter Anvin" , Michel Lespinasse , Hans-Christian Egtvedt , Linux-Arch , linux-s390@vger.kernel.org, Russell King - ARM Linux , Yoshinori Sato , Richard Weinberger , Helge Deller , the arch/x86 maintainers , "James E.J. Bottomley" , "mingo@redhat.com" , Geert Uytterhoeven , Frederic Weisbecker , Paul McKenney , =?utf-8?Q?H=C3=A5vard?= Skinnemoen , Serge Hallyn , Mike Frysinger , uml-devel , Will Deacon , Jeff Dike , Akinobu Mita , uml-user , "uclinux-dist-devel@blackfin.uclinux.org" , Thomas Gleixner , "linux-arm-kernel@lists.infradead.org" , Parisc List , "linux-kernel@vger.kernel.org" , Richard Kuo , Paul Mundt , linux-hexagon@vger.kernel.org, Martin Schwidefsky , linux390@de.ibm.com, Andrew Morton , "linuxppc-dev@lists.ozlabs.org" , David Miller X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org Arnd Bergmann writes: > On Thursday 23 May 2013, Geert Uytterhoeven wrote: >> > The problem is: trying to fix that will mean the result is a larger >> > kernel than if you just do the usual arch-implemented thing of placing >> > an defined faulting instruction at the BUG() site - which defeats the >> > purpose of turning off CONFIG_BUG. >> >> Is __builtin_unreachable() working well these days? >> > > Hmm, I just tried the trivial patch below, which seemed to do the right thing. > Needs a little more investigation, but that might actually be the correct > solution. I thought that at some point __builtin_unreachable() was the same > as "do {} while (1)", but this is not the case with the gcc I was using -- > it just tells gcc that we don't expect to ever get here. Yes. We already have this abstracted in compiler.h as the macro unreachable, so the slight modification of your patch below should handle this case. For compilers without __builtin_unreachable() unreachable() expands to do {} while(1) but an infinite loop seems reasonable and preserves the semantics of the code, unlike the current noop that is do {} while(0). > Signed-off-by: Arnd Bergmann > diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h index 7d10f96..9afff7d 100644 --- a/include/asm-generic/bug.h +++ b/include/asm-generic/bug.h @@ -108,11 +108,11 @@ extern void warn_slowpath_null(const char *file, const int line); #else /* !CONFIG_BUG */ #ifndef HAVE_ARCH_BUG -#define BUG() do {} while(0) +#define BUG() unreachable () #endif #ifndef HAVE_ARCH_BUG_ON -#define BUG_ON(condition) do { if (condition) ; } while(0) +#define BUG_ON(condition) do { if (condition) unreachable(); } while(0) #endif #ifndef HAVE_ARCH_WARN_ON