linux-kernel - Behavior of BUG() [Was: Re: [PATCH 2/5] of/fdt: add kernel command line option for dtb

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTinop4_JT4JLtdmWkydPgDDU=TyZNbtiBbgeh1dj@mail.gmail.com>
Date:	Tue, 16 Nov 2010 22:45:42 -0500
From:	Arnaud Lacombe <lacombar@...il.com>
To:	Matt Mackall <mpm@...enic.com>, linux-kernel@...r.kernel.org
Cc:	dirk.brandewie@...il.com, linux-arch@...r.kernel.org,
	linux-kbuild@...r.kernel.org,
	Grant Likely <grant.likely@...retlab.ca>
Subject: Behavior of BUG() [Was: Re: [PATCH 2/5] of/fdt: add kernel command
 line option for dtb_compat string]

Hi,

[CC: list reduced as starting a new thread, most on the context
removed as this concern a different issue.]

On Tue, Nov 16, 2010 at 7:16 PM, Grant Likely <grant.likely@...retlab.ca> wrote:
> On Tue, Nov 16, 2010 at 3:41 PM,  <dirk.brandewie@...il.com> wrote:
>> From: Dirk Brandewie <dirk.brandewie@...il.com>
>> [...]
> The kernel needs to complain *loudly* if this occurs because it
> represents a bug.  I'm tempted to say use BUG, but that would halt the
> kernel and prevent any possibility of kernel log output.
> [...]
does it ? if CONFIG_BUG is not enabled and the arch has no define for
it, the default does _nothing_:

from `include/asm-generic/bug.h':

#else /* !CONFIG_BUG */
#ifndef HAVE_ARCH_BUG
#define BUG() do {} while(0)
#endif

#ifndef HAVE_ARCH_BUG_ON
#define BUG_ON(condition) do { if (condition) ; } while(0)
#endif
[...]

gcc is triggering about ~30 warnings (like [0]) on code path using
BUG(). Most of these path assume BUG() will never return, which is not
true.

The commit message introducing this behavior state:

commit c8538a7aa5527d02c7191ac5da124efadf6a2827
Author: Matt Mackall <mpm@...enic.com>
Date:   Sun May 1 08:59:01 2005 -0700

    [PATCH] remove all kernel BUGs

    This patch eliminates all kernel BUGs, trims about 35k off the typical
    kernel, and makes the system slightly faster.

    Signed-off-by: Matt Mackall <mpm@...enic.com>
    Signed-off-by: Andrew Morton <akpm@...l.org>
    Signed-off-by: Linus Torvalds <torvalds@...l.org>

[...]

+config BUG
+       bool "BUG() support" if EMBEDDED
+       default y
+       help
+          Disabling this option eliminates support for BUG and WARN, reducing
+          the size of your kernel image and potentially quietly ignoring
+          numerous fatal conditions. You should only consider disabling this
+          option for embedded systems with no facilities for reporting errors.

So how should BUG() been used ?
 1) assuming it will never _ever_ return ?
 2) assuming it may return ?

if (1), its definition has to be changed, if (2) a lot of path have to be fixed.

Thanks in advance,
 - Arnaud

[0]: fs/dcache.c:1899:1: warning: control reaches end of non-void
function, line match an old revision, but the BUG() is still there.
--
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/