From: Arnd Bergmann <arnd@arndb.de>
To: David Daney <ddaney@caviumnetworks.com>
Cc: Alexander Beregalov <a.beregalov@gmail.com>,
linux-kernel@vger.kernel.org, David Miller <davem@davemloft.net>,
sam@ravnborg.org, dhowells@redhat.com
Subject: Re: [PATCH] BUG(): CONFIG_BUG=n version of BUG() should be unreachable()
Date: Wed, 30 Dec 2009 20:12:05 +0100 [thread overview]
Message-ID: <200912302012.05827.arnd@arndb.de> (raw)
In-Reply-To: <4B31743F.8070804@caviumnetworks.com>
On Wednesday 23 December 2009, David Daney wrote:
> David Daney wrote:
>
> Well that may be too strong an objection, but I would really recommend
> deeper consideration.
>
> If you use: #define BUG() __builtin_unreachable()
>
> which is what your patch does for GCC >= 4.5, it is truly undefined what
> happens if it is ever reached. One typical thing that might happen is
> that you start to try to execute data. It is unclear to me if it is
> preferable in the kernel to do that, rather than loop endlessly. You
> would likely achieve smaller code, but at what cost?
That is exactly what I was about to reply at first as well, but the
definition is BUG() is really "this should never happen". Normally,
i.e. CONFIG_BUG=y, we will print a stack dump and kill the running
task here. The case that Alexander is patching is for !CONFIG_BUG,
where we intentionally remove the handling for the unexpected bug
in order to reduce code size. This option is really just for people
that want to squeeze out every possibly byte from the kernel object
code, while everyone else just enables CONFIG_BUG.
Currently, this is "do { } while (0)", which on old compilers is
the best approximation of doing the right thing there, but may
cause build warnings.
__builtin_unreachable() is even better on gcc-4.5, because gcc may
save a few more instructions and not print warnings any more. Getting
into an undefined state here is not an issue, because if we get to
a BUG() statement, the system state is already known to be broken
and !CONFIG_BUG means we don't even try to to improve it any more.
The alternative "do { } while (1)" is not ideal, because an
endless loop still requires more code (typically one instruction)
than doing nothing at all.
If there are only than a handful of places that actually cause a warning,
using "do { } while (0)" (or __builtin_unreachable where available) and
fixing up the code using it might be better.
Arnd
next prev parent reply other threads:[~2009-12-30 19:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-23 1:17 [PATCH] BUG(): CONFIG_BUG=n version of BUG() should be unreachable() Alexander Beregalov
2009-12-23 1:26 ` David Daney
2009-12-23 1:37 ` David Daney
2009-12-30 19:12 ` Arnd Bergmann [this message]
2010-01-04 18:06 ` David Daney
2010-01-05 11:35 ` Arnd Bergmann
2009-12-26 18:47 ` Sam Ravnborg
2010-01-05 17:58 ` David Howells
2010-01-05 18:30 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200912302012.05827.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=a.beregalov@gmail.com \
--cc=davem@davemloft.net \
--cc=ddaney@caviumnetworks.com \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox