linux-kernel - Re: [patch] hugetlb: remove dummy definitions of HPAGE_MASK and HPAGE

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 21 Nov 2011 16:37:27 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Daney <ddaney.cavm@...il.com>
Cc:	David Rientjes <rientjes@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-mips@...ux-mips.org, ralf@...ux-mips.org,
	linux-kernel@...r.kernel.org, David Daney <david.daney@...ium.com>,
	linux-arch@...r.kernel.org, Robin Holt <holt@....com>
Subject: Re: [patch] hugetlb: remove dummy definitions of HPAGE_MASK and HPAGE_SIZE

On Mon, Nov 21, 2011 at 3:47 PM, David Daney <ddaney.cavm@...il.com> wrote:
>
> These symbols are on dead code paths, so they are eliminated by the
> compiler's Dead Code Elimination (DCE) optimizations, and the BUG() code
> never gets emitted to the final executable.

If you are so damn sure of that, then DON'T MAKE IT A BUG_ON! If you
are 100% syre, then you might as well leave out the BUG_ON() entirely.

Seriously. What's so hard to understand?

Either you are 100% sure, or you are not. If you are 100% sure, then
the BUG_ON() is pointless. And if you are not, then the BUG_ON() is
*wrong*.

Notice? The BUG_ON() is never *ever* valid. You cannot have it both
ways. So stop pushing crap, already!

So what are non-crap solutions?

 - the current one: error out at compile time (early) if somebody uses
them in invalid contexts.

   This seems to be a good case, especially since apparently no actual
current code wants to use them outside of the existing #ifdef's. And
there is no reason to think that some random MIPS-only future code is
a good enough reason to re-introduce these things

 - if you really want to use them, but expect the compiler to always
compile them away as dead code, use a non-existing function linkage,
so that you at least get a static failure at link-time for incorrect
code, rather than some random BUG_ON() at run-time that may be
impossible to find.

See? There are real solutions. BUG_ON() is not one of them.

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