linux-kernel - Re: [PATCH] x86, vsyscall: Fix build warning in vsyscall

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: <20110614211613.GB12249@elte.hu>
Date:	Tue, 14 Jun 2011 23:16:13 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Andy Lutomirski <luto@....EDU>
Cc:	Rakib Mullick <rakib.mullick@...il.com>, hpa@...or.com,
	tglx@...utronix.de, x86@...nel.org, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] x86, vsyscall: Fix build warning in vsyscall_64.c


* Andy Lutomirski <luto@....EDU> wrote:

> Aha!  You have CONFIG_BUG=n.  I'm not sure that fixing warnings for
> that case is worth it (or is even a good idea).

Especially since the warning is correct, CONFIG_BUG=n is mortally 
broken!

A BUG() turned into NOP is 100% evil, full stop.

> Can you try this patch, though:
> 
> Signed-off-by: Andy Lutomirski <luto@....edu>
> 
> diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
> index dfb0ec6..f4083f4 100644
> --- a/include/asm-generic/bug.h
> +++ b/include/asm-generic/bug.h
> @@ -107,11 +107,11 @@ extern void warn_slowpath_null(const char
> *file, const int line);
> 
>  #else /* !CONFIG_BUG */
>  #ifndef HAVE_ARCH_BUG
> -#define BUG() do {} while(0)
> +#define BUG() do { unreachable(); } while(0)
>  #endif
> 
>  #ifndef HAVE_ARCH_BUG_ON
> -#define BUG_ON(condition) do { if (condition) ; } while(0)
> +#define BUG_ON(condition) do { if (condition) unreachable(); } while(0)
>  #endif
> 
>  #ifndef HAVE_ARCH_WARN_ON
> 
> It may silence a lot of warnings, although it'll come at a cost of
> increased code size with CONFIG_BUG=n on older gcc.  On newer GCC,
> you'll get possibly faster and smaller code.

I sent such a patch ages ago but was shouted down by 'this will 
increase code size'.

I think correctness trumps code size and turning BUG() and BUG_ON() 
into a NOP is just crazy ...

Thanks,

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