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: <20140619181201.GA15963@cloud>
Date:	Thu, 19 Jun 2014 11:12:01 -0700
From:	josh@...htriplett.org
To:	Bart Van Assche <bvanassche@....org>
Cc:	Arnd Bergmann <arnd@...db.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] bug: Fix CONFIG_BUG=n BUG_ON()

On Thu, Jun 19, 2014 at 07:51:42PM +0200, Bart Van Assche wrote:
> On 06/19/14 19:21, josh@...htriplett.org wrote:
> > That's exactly what BUG_ON becomes if CONFIG_BUG=y, and that
> > significantly increases kernel size; if you want that, set CONFIG_BUG=y.
> > BUG_ON should continue to compile to nothing if CONFIG_BUG=n, or
> > CONFIG_BUG=n has no reason to exist.
> 
> Hello Josh,
> 
> I wasn't aware that the current behavior of BUG_ON() with CONFIG_BUG=n
> was intentional. The reason I started looking into this is because
> different compiler warnings are generated for code with BUG_ON(1)
> statements when building against a kernel with CONFIG_BUG=y or
> CONFIG_BUG=n. There is an easy alternative though: changing BUG_ON(1)
> into BUG() in my code.

You should definitely never use BUG_ON(1); use BUG() if you want to say
"this (and the code after it) should never be reached".  That should
also avoid the compiler warnings.

If you encounter any compiler warnings caused by CONFIG_BUG=n that go
away with CONFIG_BUG=y, please do report them; those should get fixed.

- Josh Triplett
--
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