lkml.org 
[lkml]   [2004]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [2.6 patch][3/3] mm/ BUG -> BUG_ON conversions
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

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

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.377 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site