All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: David Daney <ddaney.cavm@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	David Rientjes <rientjes@google.com>,
	linux-mips@linux-mips.org, ralf@linux-mips.org,
	linux-kernel@vger.kernel.org,
	David Daney <david.daney@cavium.com>,
	linux-arch@vger.kernel.org, Robin Holt <holt@sgi.com>
Subject: Re: [patch] hugetlb: remove dummy definitions of HPAGE_MASK and HPAGE_SIZE
Date: Mon, 21 Nov 2011 15:53:31 -0800	[thread overview]
Message-ID: <20111121155331.a1726ffe.akpm@linux-foundation.org> (raw)
In-Reply-To: <4ECAE314.9060209@gmail.com>

On Mon, 21 Nov 2011 15:47:32 -0800
David Daney <ddaney.cavm@gmail.com> wrote:

> Just to expand on this lovely topic...
> 
> On 11/21/2011 02:43 PM, Linus Torvalds wrote:
> > On Mon, Nov 21, 2011 at 2:23 PM, David Daney<ddaney.cavm@gmail.com>  wrote:
> >>
> >> This whole comment strikes me as somewhat dishonest, as at the time David
> >> Rientjes wrote it, he knew that there were dependencies on these symbols in
> >> the linux-next tree.
> >>
> >> Now we can add these:
> >> +#define HPAGE_SHIFT    ({ BUG(); 0; })
> >> +#define HPAGE_SIZE     ({ BUG(); 0; })
> >> +#define HPAGE_MASK     ({ BUG(); 0; })
> >
> > Hell no.
> >
> > We don't do run-time BUG() things. No way, no how.
> >
> 
> 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.
> 
> I agree that it is not the best thing to do, but given the current state 
> of the art in build bug macros, it is the best we could have done.
> 
> What I think we need instead, and for which I will send a patch soon, is 
> something like this:
> 
> extern void you_are_screwed() __attribute__ ((error("BUILD_BUG_ON_USED 
> failed")));
> #define BUILD_BUG_ON_USED() you_are_screwed()
> #define HPAGE_SHIFT    ({ BUILD_BUG_ON_USED(); 0; })
> 
> This allows us to use the symbols in straight line C code without a ton 
> of ugly #ifdefery, but give us build time error checking.

The way we usually handle that is to emit a call to a
this_function_does_not_exist(), so it fails at link time.

I guess we should do that to all those follow_hugetlb_page() and
friends.

gcc has had issues at times where it incorrectly emits references to
this_function_does_not_exist(), but that hasn't happened in a couple of
years as far as I know.

  reply	other threads:[~2011-11-21 23:53 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-17 21:57 [PATCH v2 0/2] Dummy HPAGE_* constants for !CONFIG_HUGETLB_PAGE David Daney
2011-11-17 21:57 ` [PATCH v2 1/2] hugetlb: Provide a default HPAGE_SHIFT if !CONFIG_HUGETLB_PAGE David Daney
2011-11-17 21:57 ` [PATCH v2 2/2] hugetlb: Provide safer dummy values for HPAGE_MASK and HPAGE_SIZE David Daney
2011-11-17 23:28   ` Andrew Morton
2011-11-17 23:38     ` David Daney
2011-11-18  8:56   ` Sergei Shtylyov
2011-11-18 17:14     ` David Daney
2011-11-17 23:22 ` [PATCH v2 0/2] Dummy HPAGE_* constants for !CONFIG_HUGETLB_PAGE David Rientjes
2011-11-17 23:22   ` [patch] hugetlb: remove dummy definitions of HPAGE_MASK and HPAGE_SIZE David Rientjes
2011-11-17 23:35     ` Andrew Morton
2011-11-17 23:44       ` David Rientjes
2011-11-17 23:52         ` David Daney
2011-11-17 23:57           ` Andrew Morton
2011-11-17 23:57           ` David Rientjes
2011-11-21 22:23     ` David Daney
2011-11-21 22:43       ` Linus Torvalds
2011-11-21 23:23         ` David Daney
2011-11-21 23:43           ` Linus Torvalds
2011-11-21 23:50             ` Andrew Morton
2011-11-22 20:41               ` Andi Kleen
2011-11-22 20:41                 ` Andi Kleen
2011-11-21 23:47         ` David Daney
2011-11-21 23:53           ` Andrew Morton [this message]
2011-11-22  0:37           ` Linus Torvalds
2011-11-22  0:48             ` David Daney
2011-11-22  0:55               ` Linus Torvalds
2011-11-21 22:48       ` David Rientjes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111121155331.a1726ffe.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=david.daney@cavium.com \
    --cc=ddaney.cavm@gmail.com \
    --cc=holt@sgi.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=rientjes@google.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.