From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from caramon.arm.linux.org.uk (caramon.arm.linux.org.uk [IPv6:2002:4e20:1eda::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 783BC2C0178 for ; Thu, 23 May 2013 20:32:36 +1000 (EST) Date: Thu, 23 May 2013 11:29:34 +0100 From: Russell King - ARM Linux To: "Eric W. Biederman" Subject: Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it. Message-ID: <20130523102934.GN18614@n2100.arm.linux.org.uk> References: <519DCBEF.3090208@asianux.com> <20130523090534.GJ18614@n2100.arm.linux.org.uk> <201305231139.38233.arnd@arndb.de> <878v369fdd.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <878v369fdd.fsf@xmission.com> Sender: Russell King - ARM Linux Cc: Catalin Marinas , Linux-sh list , Chen Gang , Heiko Carstens , "paulus@samba.org" , "H. Peter Anvin" , Michel Lespinasse , Hans-Christian Egtvedt , Linux-Arch , linux-s390@vger.kernel.org, uml-devel , Yoshinori Sato , Richard Weinberger , Helge Deller , the arch/x86 maintainers , "James E.J. Bottomley" , "mingo@redhat.com" , Geert Uytterhoeven , Frederic Weisbecker , Paul McKenney , =?iso-8859-1?Q?H=E5vard?= Skinnemoen , Serge Hallyn , Mike Frysinger , Arnd Bergmann , 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 List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, May 23, 2013 at 03:09:50AM -0700, Eric W. Biederman wrote: > 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). Semantics of the code really don't come in to it if you use unreachable(). unreachable() is an effective do { } while (0) to the compiler. It just doesn't warn about it anymore. It's actually worse than that - it's permission to the compiler to just stop considering flow control at that point and do anything it likes with the following instruction slot. What __builtin_unreachable() means to the compiler is "we will *never* get here". That isn't the case for BUG() - BUG() means "we hope that we will never get here, but we might, and if we do your data is in grave danger." We should either have something at that point (like a call to a function which panics) or remove the ability to turn off CONFIG_BUG and anyone who cares about kernel size needs to come up with a single trapping instruction BUG() implementation.