Re: [2.6 patch][3/3] mm/ BUG -> BUG_ON conversions

[Jens Axboe <axboe@suse.de>]

On Sun, Aug 29 2004, Adrian Bunk wrote:
> On Sun, Aug 29, 2004 at 03:01:56PM +0200, Jens Axboe wrote:
> > On Sun, Aug 29 2004, Oliver Neukum wrote:
> > > Am Sonntag, 29. August 2004 14:03 schrieb Jens Axboe:
> > > > > The intention is, to add an option that lets BUG/BUG_ON/WARN_ON/PAGE_BUG 
> > > > > do nothing. This option should be hidden under EMBEDDED.
> > > > > 
> > > > > In some environments, this seems to be desirable.
> > > > 
> > > > That only makes sense if you are using BUG incorrectly. A BUG()
> > > > condition is something that is non-recoverable, undefining that doesn't
> > > > make any sense regardless of the environment.
> > > 
> > > Why not? Giving reports about unrecoverable errors is sensible
> > > only if the report can be read. On system this is not the case, you
> > > can just salvage the memory and let it crash.
> > 
> > "Unrecoverable" can quite easily mean "something really bad has
> > happened, corruption imminent". So maybe you would want BUG/BUG_ON to
> > restart the box there, the restart-on-panic should help you there.
> >...
> 
> The current sh/sh64 implementation doesn't seem to do any of the things 
> you expect from BUG:
> 
> #define BUG() do { \
>         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
>         asm volatile("nop"); \
> } while (0)

Well too bad for them, I'm glad I'm not trusting any data to a machine
with that architecture.

-- 
Jens Axboe