Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Thu, May 23, 2013 at 12:59:43PM +0200, Arnd Bergmann wrote:
> On Thursday 23 May 2013, 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 must be missing something, to me the two descriptions mean the same thing.

To me, the current text suggests that we still detect the fatal condition
but the code continues to execute in a manner controlled by the program.

The latter is uncontrolled code (or data) execution in ways unspecified
by the program.

> You don't just want to avoid the code for printing the bug message and
> the invalid instruction, we also want the compiler to not emit the 
> function call or check the enum for unexpected values. The meaning of
> BUG() is really that person writing that statement was sure it cannot
> happen unless there is a bug in the kernel, which has likely already
> corrupted data. Printing a diagnostic at this point is nice if someone
> is there to look at it, but letting the kernel do further actions that
> may be undefined is not going to make things worse.

I'm not talking about printing a diagnostic.  I'm talking about the CPU
remaining under the control of the program it is running - that being
the Linux kernel.

With CONFIG_BUG unset, turning on things like reboot-on-panic and such
like is worthless.  Arguably even is having a hardware watchdog - because
even if you hit one of these BUG() conditions where the CPU goes off and
does its own thing, it might be sufficient that the system is still able
to take care of the watchdog.

This is the problem you guys are missing - unreachable() means "we lose
control of the CPU at this point".

If you have an embedded system and you've taken out all the printk()
stuff, you most certainly want the system to do _something_ if you hit
an unexpected condition.