From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it. Date: Tue, 28 May 2013 10:19:10 +0200 Message-ID: <20130528081910.GA29557@gmail.com> References: <519DCBEF.3090208@asianux.com> <20130523090534.GJ18614@n2100.arm.linux.org.uk> <201305231139.38233.arnd@arndb.de> <20130523100409.GK18614@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20130523100409.GK18614@n2100.arm.linux.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" To: 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 , H?vard Skinnemoen Serge Hallyn List-Id: linux-arch.vger.kernel.org * Russell King - ARM Linux wrote: > 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". I'm fine with adding your text as a clarification - but I think 'quietly ignoring fatal conditions' very much implies an undefined outcome if that unexpected condition does occur: the code might crash, it might corrupt memory or it might do some other unexpected thing. There are many other places that do a BUG_ON() of a NULL pointer or so, or of a zero refcount, or a not held lock - and turning the BUG_ON() off makes the code unpredictable _anyway_ - even if the compiler does not notice an uninitialized variable. So pretty much any weakening of BUG_ON() _will_ make the kernel more unpredictable. > 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? It will often continue blindly into the unknown even if the compiler is happy ... The only difference is that it's "unpredictable" in a way not visible from the C code: the code won't necessarily fall through the BUG() when hitting that condition - although in practice it probably will. So I think the same principle applies to it as to any other debugging code: it's fine to be able to turn debugging off. It's a performance versus kernel robustness/determinism trade-off. Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it. Date: Tue, 28 May 2013 10:19:10 +0200 Message-ID: <20130528081910.GA29557@gmail.com> References: <519DCBEF.3090208@asianux.com> <20130523090534.GJ18614@n2100.arm.linux.org.uk> <201305231139.38233.arnd@arndb.de> <20130523100409.GK18614@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=J5MkUJWSQg/NFFikZq75PF1+q/BC973HP48T8i94XAE=; b=riKS1phTM6JKIkVhHYzTrVZQSEmPXyRU3wvr+SbFfBb13nDy5RisEgLAn3LpPxSeqa BnyJAP1DR2F89Yif1XZIBxtP5RNMYf8QBaS+KBiEk/FM4GIi8qGac+uN/5WRE7juCVTE HL6Zqdl46xUzuXToAzNlieR6qXM0NQNQ2YFVL7W/jm17nD2iJCUlfXj6K7/wRFMjP207 qDjmwLLQrpkq66+hXvg5Saa/yI3zrCBHKjVKiKyWaB+/F+WIlPqem8ejY9gKpTHtwNsA VmGkfSKhT09EW+EtGHf14A4oTy55S12EAwqo/WHW4IEqnn6f0n+OFtnGleMLnWuHyVpV feMw== Content-Disposition: inline In-Reply-To: <20130523100409.GK18614@n2100.arm.linux.org.uk> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" To: 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 , H?vard Skinnemoen , Serge Hallyn * Russell King - ARM Linux wrote: > 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". I'm fine with adding your text as a clarification - but I think 'quietly ignoring fatal conditions' very much implies an undefined outcome if that unexpected condition does occur: the code might crash, it might corrupt memory or it might do some other unexpected thing. There are many other places that do a BUG_ON() of a NULL pointer or so, or of a zero refcount, or a not held lock - and turning the BUG_ON() off makes the code unpredictable _anyway_ - even if the compiler does not notice an uninitialized variable. So pretty much any weakening of BUG_ON() _will_ make the kernel more unpredictable. > 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? It will often continue blindly into the unknown even if the compiler is happy ... The only difference is that it's "unpredictable" in a way not visible from the C code: the code won't necessarily fall through the BUG() when hitting that condition - although in practice it probably will. So I think the same principle applies to it as to any other debugging code: it's fine to be able to turn debugging off. It's a performance versus kernel robustness/determinism trade-off. Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it. Date: Tue, 28 May 2013 10:19:10 +0200 Message-ID: <20130528081910.GA29557@gmail.com> References: <519DCBEF.3090208@asianux.com> <20130523090534.GJ18614@n2100.arm.linux.org.uk> <201305231139.38233.arnd@arndb.de> <20130523100409.GK18614@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 , H?vard Skinnemoen , Serge Hallyn Return-path: In-Reply-To: <20130523100409.GK18614@n2100.arm.linux.org.uk> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org * Russell King - ARM Linux wrote: > 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". I'm fine with adding your text as a clarification - but I think 'quietly ignoring fatal conditions' very much implies an undefined outcome if that unexpected condition does occur: the code might crash, it might corrupt memory or it might do some other unexpected thing. There are many other places that do a BUG_ON() of a NULL pointer or so, or of a zero refcount, or a not held lock - and turning the BUG_ON() off makes the code unpredictable _anyway_ - even if the compiler does not notice an uninitialized variable. So pretty much any weakening of BUG_ON() _will_ make the kernel more unpredictable. > 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? It will often continue blindly into the unknown even if the compiler is happy ... The only difference is that it's "unpredictable" in a way not visible from the C code: the code won't necessarily fall through the BUG() when hitting that condition - although in practice it probably will. So I think the same principle applies to it as to any other debugging code: it's fine to be able to turn debugging off. It's a performance versus kernel robustness/determinism trade-off. Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it. Date: Tue, 28 May 2013 10:19:10 +0200 Message-ID: <20130528081910.GA29557@gmail.com> References: <519DCBEF.3090208@asianux.com> <20130523090534.GJ18614@n2100.arm.linux.org.uk> <201305231139.38233.arnd@arndb.de> <20130523100409.GK18614@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20130523100409.GK18614@n2100.arm.linux.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" List-Archive: List-Post: To: 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 , H?vard Skinnemoen List-ID: * Russell King - ARM Linux wrote: > 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". I'm fine with adding your text as a clarification - but I think 'quietly ignoring fatal conditions' very much implies an undefined outcome if that unexpected condition does occur: the code might crash, it might corrupt memory or it might do some other unexpected thing. There are many other places that do a BUG_ON() of a NULL pointer or so, or of a zero refcount, or a not held lock - and turning the BUG_ON() off makes the code unpredictable _anyway_ - even if the compiler does not notice an uninitialized variable. So pretty much any weakening of BUG_ON() _will_ make the kernel more unpredictable. > 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? It will often continue blindly into the unknown even if the compiler is happy ... The only difference is that it's "unpredictable" in a way not visible from the C code: the code won't necessarily fall through the BUG() when hitting that condition - although in practice it probably will. So I think the same principle applies to it as to any other debugging code: it's fine to be able to turn debugging off. It's a performance versus kernel robustness/determinism trade-off. Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: Ingo Molnar Date: Tue, 28 May 2013 10:19:10 +0200 From: Ingo Molnar Message-ID: <20130528081910.GA29557@gmail.com> References: <519DCBEF.3090208@asianux.com> <20130523090534.GJ18614@n2100.arm.linux.org.uk> <201305231139.38233.arnd@arndb.de> <20130523100409.GK18614@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130523100409.GK18614@n2100.arm.linux.org.uk> Subject: Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it. To: Russell King - ARM Linux Cc: Arnd Bergmann , Geert Uytterhoeven , Chen Gang , H?vard 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 , Linus Torvalds List-ID: * Russell King - ARM Linux wrote: > 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". I'm fine with adding your text as a clarification - but I think 'quietly ignoring fatal conditions' very much implies an undefined outcome if that unexpected condition does occur: the code might crash, it might corrupt memory or it might do some other unexpected thing. There are many other places that do a BUG_ON() of a NULL pointer or so, or of a zero refcount, or a not held lock - and turning the BUG_ON() off makes the code unpredictable _anyway_ - even if the compiler does not notice an uninitialized variable. So pretty much any weakening of BUG_ON() _will_ make the kernel more unpredictable. > 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? It will often continue blindly into the unknown even if the compiler is happy ... The only difference is that it's "unpredictable" in a way not visible from the C code: the code won't necessarily fall through the BUG() when hitting that condition - although in practice it probably will. So I think the same principle applies to it as to any other debugging code: it's fine to be able to turn debugging off. It's a performance versus kernel robustness/determinism trade-off. Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (not verified)) by ozlabs.org (Postfix) with ESMTPS id AAC5C2C02FF for ; Tue, 28 May 2013 18:19:19 +1000 (EST) Received: by mail-wg0-f44.google.com with SMTP id a12so5166767wgh.35 for ; Tue, 28 May 2013 01:19:14 -0700 (PDT) Sender: Ingo Molnar Date: Tue, 28 May 2013 10:19:10 +0200 From: Ingo Molnar To: Russell King - ARM Linux Subject: Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it. Message-ID: <20130528081910.GA29557@gmail.com> References: <519DCBEF.3090208@asianux.com> <20130523090534.GJ18614@n2100.arm.linux.org.uk> <201305231139.38233.arnd@arndb.de> <20130523100409.GK18614@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20130523100409.GK18614@n2100.arm.linux.org.uk> 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 , H?vard 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 , Linus Torvalds , "linux-kernel@vger.kernel.org" , Richard Kuo , Paul Mundt , "Eric W. Biederman" , 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: , * Russell King - ARM Linux wrote: > 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". I'm fine with adding your text as a clarification - but I think 'quietly ignoring fatal conditions' very much implies an undefined outcome if that unexpected condition does occur: the code might crash, it might corrupt memory or it might do some other unexpected thing. There are many other places that do a BUG_ON() of a NULL pointer or so, or of a zero refcount, or a not held lock - and turning the BUG_ON() off makes the code unpredictable _anyway_ - even if the compiler does not notice an uninitialized variable. So pretty much any weakening of BUG_ON() _will_ make the kernel more unpredictable. > 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? It will often continue blindly into the unknown even if the compiler is happy ... The only difference is that it's "unpredictable" in a way not visible from the C code: the code won't necessarily fall through the BUG() when hitting that condition - although in practice it probably will. So I think the same principle applies to it as to any other debugging code: it's fine to be able to turn debugging off. It's a performance versus kernel robustness/determinism trade-off. Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 From: mingo@kernel.org (Ingo Molnar) Date: Tue, 28 May 2013 10:19:10 +0200 Subject: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it. In-Reply-To: <20130523100409.GK18614@n2100.arm.linux.org.uk> References: <519DCBEF.3090208@asianux.com> <20130523090534.GJ18614@n2100.arm.linux.org.uk> <201305231139.38233.arnd@arndb.de> <20130523100409.GK18614@n2100.arm.linux.org.uk> Message-ID: <20130528081910.GA29557@gmail.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org * Russell King - ARM Linux wrote: > 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". I'm fine with adding your text as a clarification - but I think 'quietly ignoring fatal conditions' very much implies an undefined outcome if that unexpected condition does occur: the code might crash, it might corrupt memory or it might do some other unexpected thing. There are many other places that do a BUG_ON() of a NULL pointer or so, or of a zero refcount, or a not held lock - and turning the BUG_ON() off makes the code unpredictable _anyway_ - even if the compiler does not notice an uninitialized variable. So pretty much any weakening of BUG_ON() _will_ make the kernel more unpredictable. > 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? It will often continue blindly into the unknown even if the compiler is happy ... The only difference is that it's "unpredictable" in a way not visible from the C code: the code won't necessarily fall through the BUG() when hitting that condition - although in practice it probably will. So I think the same principle applies to it as to any other debugging code: it's fine to be able to turn debugging off. It's a performance versus kernel robustness/determinism trade-off. Thanks, Ingo