lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 22 Dec 2006 21:06:50 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Andrew Morton <akpm@...l.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Jeremy Fitzhardinge <jeremy@...p.org>,
	Linus Torvalds <torvalds@...l.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch] change WARN_ON back to "BUG: at ..."

On Fri, 2006-12-22 at 12:04 -0800, Andrew Morton wrote:
> I've always felt that it is wrong (or at least misleading) that WARN_ON
> prints "BUG".  It would have been better if it had said "WARNING", and only
> BUG_ON says "BUG".
> 
> But lots of people have now written downstream log-parsing tools which
> might break due to this change, so I'm inclined to go with Ingo's patch,
> and restore the old (il)logic.

>>From hearing what Ingo has to say about this, it seems that calling it
WARING was wrong in the first place.

BUG (and BUG_ON) are really fatal bugs.  Meaning that if you continue,
you will corrupt the system.

WARN_ON is still a BUG, but we know enough about it that we can just
cripple the system so that it doesn't break anything.  But keeps the
system running so that someone can either read the logs, and perhaps, if
it happens to a developer, be able to do some more diagnostics.

But really, the WARN_ON should only be used when the system did
something that is as bad as a BUG, but you don't need to crash the
system since you can prevent data from being corrupted.  But you want to
flag this so that it can be fixed. Since it really is a BUG!  Calling
BUG_ON while the user is in X is really hopeless, since they may never
know why their system just crashed.

The kernel already prints out "warning" for other things that are not
bugs. Usually a warning means that something might not be compatible.
Or something might degrade performance.  Or you have buggy hardware.
But a "warning" doesn't usually mean a kernel BUG.  WARN_ON on the other
hand should only be used where the cause of the WARN_ON was due to a bug
in the kernel, hence, the word "BUG" should be used.

At least with the -rt patch, we get reports of a BUG happening where it
was from a WARN_ON, and this is a Good Thing(TM).  I can foresee users
ignoring a warning message if that's all they see, and they don't
realize that something has been crippled, and the system is unstable.

Sometimes a WARN_ON can be a cause of a later BUG.  And since the BUG
output has a "cut here" we may not get the output of the true bug.
Users are much more apt to report messages of BUG than WARNING.  So, I
totally agree with Ingo, we need people to see these as BUGs, and report
them whenever they happen. Because when it comes down to it, the warning
is about a bug.

-- Steve

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ