linux-kernel - Re: [patch 2.6.28-rc6] when to BUG(), and when to not BUG()

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] [day] [month] [year] [list]

Message-Id: <20081129201930.a591395b.akpm@linux-foundation.org>
Date:	Sat, 29 Nov 2008 20:19:30 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	David Brownell <david-b@...bell.net>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Hans Verkuil <hverkuil@...all.nl>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [patch 2.6.28-rc6] when to BUG(), and when to not BUG()

On Sat, 29 Nov 2008 19:21:30 -0800 David Brownell <david-b@...bell.net> wrote:

> From: David Brownell <dbrownell@...rs.sourceforge.net>
> 
> Provide some basic advice about when to use BUG()/BUG_ON():
> never, unless there's really no better option.
> 
> This matches my understanding of the standard policy ... which
> seems not to be written down so far, outside of LKML messages
> that I haven't bookmarked.
> 
> Signed-off-by: David Brownell <dbrownell@...rs.sourceforge.net>
> Cc: Hans Verkuil <hverkuil@...all.nl>
> ---
> This arguably belongs in patch checklists too... but I figure we
> should start by flushing out any contrary opinions.
> 
>  include/asm-generic/bug.h |   17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> --- a/include/asm-generic/bug.h
> +++ b/include/asm-generic/bug.h
> @@ -20,6 +20,17 @@ struct bug_entry {
>  #define BUGFLAG_WARNING	(1<<0)
>  #endif	/* CONFIG_GENERIC_BUG */
>  
> +/*
> + * Don't use BUG() or BUG_ON() unless there's really no way out; one
> + * example might be detecting data structure corruption in the middle
> + * of an operation that can't be backed out of.  If the (sub)system
> + * can somehow continue operating, perhaps with reduced functionality,
> + * it's probably not BUG-worthy.
> + *
> + * If you're tempted to BUG(), think again:  is completely giving up
> + * really the *only* solution?  There are usually better options, where
> + * users don't need to reboot ASAP and can mostly shut down cleanly.
> + */
>  #ifndef HAVE_ARCH_BUG
>  #define BUG() do { \
>  	printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \
> @@ -31,6 +42,12 @@ struct bug_entry {
>  #define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while(0)
>  #endif
>  
> +/*
> + * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report
> + * significant issues that need prompt attention if they should ever
> + * appear at runtime.  Use the versions with printk format strings
> + * to provide better diagnostics.
> + */
>  #ifndef __WARN
>  #ifndef __ASSEMBLY__
>  extern void warn_on_slowpath(const char *file, const int line);

I don't disagree.

One reason for trying to keep going rather than going BUG is that it
increases the chances that the information about the bug gets into the
logs, gets sent across netconsole, etc.

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