From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 23 May 2013 11:04:09 +0100 From: Russell King - ARM Linux Message-ID: <20130523100409.GK18614@n2100.arm.linux.org.uk> References: <519DCBEF.3090208@asianux.com> <20130523090534.GJ18614@n2100.arm.linux.org.uk> <201305231139.38233.arnd@arndb.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201305231139.38233.arnd@arndb.de> Sender: Russell King - ARM Linux Subject: Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it. To: Arnd Bergmann Cc: Geert Uytterhoeven , Chen Gang , =?iso-8859-1?Q?H=E5vard?= Skinnemoen , Hans-Christian Egtvedt , Mike Frysinger , Yoshinori Sato , Richard Kuo , "James E.J. Bottomley" , Helge Deller , Benjamin Herrenschmidt , "paulus@samba.org" , Martin Schwidefsky , Heiko Carstens , linux390@de.ibm.com, Paul Mundt , Jeff Dike , Richard Weinberger , Thomas Gleixner , "mingo@redhat.com" , "H. Peter Anvin" , the arch/x86 maintainers , "Eric W. Biederman" , Serge Hallyn , Paul McKenney , Frederic Weisbecker , David Miller , Andrew Morton , Akinobu Mita , Catalin Marinas , Michel Lespinasse , Will Deacon , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "uclinux-dist-devel@blackfin.uclinux.org" , linux-hexagon@vger.kernel.org, Parisc List , "linuxppc-dev@lists.ozlabs.org" , linux-s390@vger.kernel.org, Linux-sh list , uml-devel , uml-user , Linux-Arch List-ID: On Thu, May 23, 2013 at 11:39:37AM +0200, Arnd Bergmann wrote: > 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. All this is doing is hiding the warning, nothing more. What the compiler does is this: beq 1f ... some asm code ... __builtin_reachable() point maybe a literal table 1: ... some asm code doing some other part of the function ... and what will happen is that the first block of asm will fall through the (possibly present) literal table into the following asm code. So, as specified in the gcc manual, if you ever hit a __builtin_unreachable() point, your program is undefined (as in, the behaviour of it can no longer be known.) We can't make that guarantee with BUG() - because sometimes they do fire and sometimes in the most unlikely scenarios, particularly if you're not looking, or at the most inconvenient time. So, if you want to use this, then you should update the CONFIG_BUG text to include a warning to this effect: Warning: if CONFIG_BUG is turned off, and control flow reaches a BUG(), the system behaviour will be undefined. so that people can make an informed choice about this, because at the moment: Disabling this option eliminates support for BUG and WARN, reducing the size of your kernel image and potentially quietly ignoring numerous fatal conditions. You should only consider disabling this option for embedded systems with no facilities for reporting errors. Just say Y. will become completely misleading. Turning this option off will _not_ result in "quietly ignoring numerous fatal conditions". And I come back to one of my previous arguments - is it not better to panic() if we hit one of these conditions so that the system can try to do a panic-reboot rather than continue blindly into the unknown?