[2/3] 2.6.22-rc2: known regressions v2
mingo at elte.hu
Thu May 24 15:37:40 EDT 2007
* Linus Torvalds <torvalds at linux-foundation.org> wrote:
> > Looks like this is in DRM code:
> > BUG: at include/linux/slub_def.h:88 kmalloc_index()
> I'm going to change that "BUG:" to "WARNING:".
> I know some people disagreed with it (ie Ingo), but I think that's
> total and utter bullshit.
> It's a warning. Right now that "BUG:" message makes people all scared
> about something that is not fatal at all, just a note that something
> hasn't been converted, but is expected to work absolutely fine.
> Calling it a bug is idiotic.
i very much agree that this kmalloc_index() one shouldnt be called a
"BUG: ", but if you look at the majority of WARN_ON() instances they are
checks for clear, serious kernel bugs. Very often we use WARN_ON() not
to signal that it's just a harmless warning, but because we do not want
to bring the system down via a BUG_ON(). The API is misnamed for sure,
but still, the purpose and current practice is clear: to signal kernel
To quantify this a bit more objectively i just did a "grep WARN_ON
kernel/*.c" and randomly picked 10 out of the 113 WARN_ON()'s:
kernel/fork.c: WARN_ON(!(tsk->exit_state & (EXIT_DEAD | EXIT_ZOMBIE)));
kernel/hrtimer.c: WARN_ON_ONCE(timer->cb_mode == HRTIMER_CB_IRQSAFE_NO_SOFTIRQ);
kernel/sched.c: if (DEBUG_LOCKS_WARN_ON((preempt_count() < 0)))
and reviewed each instance, each and every one of these warnings is a
serious kernel bug that i would not 'warn' about, but what i'd like to
see reported ASAP. [ In fact i added 5 of these WARN_ON()s :-/ ] But
maybe that's just me?
now regarding the naming of this API, i'd very much agree to do this
WARN_ON => BUG_ON
BUG_ON => CRASH_ON
and make WARN_ON() print a "WARNING: ".
and i signalled this in the original discussion too a few months ago
when i opposed the watering-down of the WARN_ON printk.
OTOH i dont feel that strongly about all this :-)
More information about the linux-pcmcia