linux-kernel - Re: [patch] change WARN

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 00:57:32 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Linus Torvalds <torvalds@...l.org>, Andrew Morton <akpm@...l.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch] change WARN_ON back to "BUG: at ..."

* Jeremy Fitzhardinge <jeremy@...p.org> wrote:

> What's the intent of WARN_ON?  Presumably its different from BUG_ON, 
> otherwise you could just use BUG_ON.  Or if not, why not just have 
> BUG_ON?  I think in practice many WARN_ONs are clearly not intended to 
> be as serious as BUG_ON: [...]

you are quite wrong. For example i cannot remember the last time i added 
a BUG_ON() to the core kernel, because a BUG_ON() in core code only 
makes it harder to get the log output back to the developer! Often the 
system is still alive enough to get the information out but crashing it 
via BUG_ON() hides the messages . So for example i exclusively use 
WARN_ON() in core kernel code.

> [...] they warn about unimplemented things, transient hiccups, 
> clarifications of errno returns, etc. [...]

Your claims defy reality: i just checked the 200+ WARN_ON()s that are in 
linux/*/*.c, and /none/ is a 'transient' failure or hickup or 
'clarification'. Each one i checked signals a real kernel bug that i'd 
not want a production system to have. Non-fatal messages should and do 
get a normal KERN_ printk.

an no, i dont want to do a large-scale rename in either direction. Let 
it be up to the developer whether he wants to crash the kernel upon 
seeing a bug or not. But one thing is sure: a WARN_ON() is a kernel bug 
just as much as a BUG_ON(), in 99% of the cases.

here's the history of these primitives: BUG() used to be the only 
primitive back in the days, then came BUG_ON() and iirc i was the one 
who added WARN_ON() years ago, as a mechanism to signal kernel bugs in a 
less destructive way. And that's how it's used in the kernel. If you 
disagree and still understand it to be different, that's really your 
problem i think ...

	Ingo
-
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/