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

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

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

On 11/21/2011 04:37 PM, Linus Torvalds wrote:
> 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?

Really Linus, did you read the other half of the message you quoted?

The part you quote above explains the reason things are the way they 
currently are.

The second part, that I think you may have missed, is the part I had 
hoped you would read...

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

... because it said exactly what you say above.

I will send you a patch within the next two hours that shows what may be 
an acceptable solution.

Thanks,
David Daney
--
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/