Re: [PATCH] BUG(): CONFIG_BUG=n version of BUG() should be unreachable()

[Arnd Bergmann]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/