linux-kernel - Re: 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: Windows password security audit tool. GUI, reports in PDF.

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

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

On Tue, 2010-11-16 at 23:29 -0500, Arnaud Lacombe wrote:
> Hi,
> 
> On Tue, Nov 16, 2010 at 11:13 PM, Grant Likely
> <grant.likely@...retlab.ca> wrote:
> > On Tue, Nov 16, 2010 at 8:45 PM, Arnaud Lacombe <lacombar@...il.com> wrote:
> >> 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.
> >
> > As far as I know, BUG() is not supposed to return.  Period.
> >
> but the code I pointed out _do_ return.
> 
> > The patch
> > below is part of the linux-tiny work, and should only ever be used on
> > embedded systems where small size is more important than debugability.
> >
> AFAIK, this is not precised anywhere, but I may not have search enough.

Read the help for CONFIG_BUG and CONFIG_EMBEDDED.

> Matt, any reason the generic code does not just spin (or OOPS) and
> marked __noreturn in any case ?

Yes. Spinning and oopsing take space. Function calls take space. The
whole damn point of this option is to say is _we don't care about BUGs,
we care about space_. In other words, this code is a hack and is marked
as such. Arguing about "correctness" here is a waste of time, it's
intentionally not correct.

I seem to recall attempting to fool GCC with a __noreturn and failing.

-- 
Mathematics is the supreme nostalgia of our time.


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