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]
Message-ID: <AANLkTinz27cfdNKEtyUo9f3nuw+XbZ2Osz0ThRiOQnnL@mail.gmail.com>
Date:	Tue, 16 Nov 2010 23:29:57 -0500
From:	Arnaud Lacombe <lacombar@...il.com>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Matt Mackall <mpm@...enic.com>, 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]

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.

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

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