linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Daney <ddaney.cavm@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org,
	linux-kernel@vger.kernel.org,
	David Daney <david.daney@cavium.com>,
	David Rientjes <rientjes@google.com>
Subject: Re: [PATCH v2 2/2] hugetlb: Provide safer dummy values for HPAGE_MASK and HPAGE_SIZE
Date: Thu, 17 Nov 2011 15:38:42 -0800	[thread overview]
Message-ID: <4EC59B02.7060804@gmail.com> (raw)
In-Reply-To: <20111117152841.dc962d9d.akpm@linux-foundation.org>

On 11/17/2011 03:28 PM, Andrew Morton wrote:
> On Thu, 17 Nov 2011 13:57:30 -0800
> David Daney<ddaney.cavm@gmail.com>  wrote:
>
>> From: David Daney<david.daney@cavium.com>
>>
>> It was pointed out by David Rientjes that the dummy values for
>> HPAGE_MASK and HPAGE_SIZE are quite unsafe.  It they are inadvertently
>> used with !CONFIG_HUGETLB_PAGE, compilation would succeed, but the
>> resulting code would surly not do anything sensible.
>>
>> Place BUG() in the these dummy definitions, as we do in similar
>> circumstances in other places, so any abuse can be easily detected.
>>
>> Since the only sane place to use these symbols when
>> !CONFIG_HUGETLB_PAGE is on dead code paths, the BUG() cause any actual
>> code to be emitted by the compiler.
>
> I assume you meant "omitted" here.

I jumbled it up.  It should read:

... the BUG() will not cause any actual code to be emitted by the 
compiler.  In fact I have verified this on both MIPS64 and x86_64 kernels.

I could re-spin the patch with a corrected changelog if desired.

>
> But I don't think it's true.  Any such code would occur after testing
> is_vm_hugetlb_page() or similar, and would have been omitted anyway.
>

The point being that we are doing:

if (is_vm_hugetlb_page(vma)) {
	/* Do something with HPAGE_MASK*/
} else {
	/* Do something with PAGE_MASK */
}

In the !CONFIG_HUGETLB_PAGE case we have:
static inline int is_vm_hugetlb_page(struct vm_area_struct *vma)
{
	return 0;
}

The compiler sees that the usage of the dummy definitions is in a dead 
code path and nothing is emitted.

>> --- a/include/linux/hugetlb.h
>> +++ b/include/linux/hugetlb.h
>> @@ -111,8 +111,9 @@ static inline void copy_huge_page(struct page *dst, struct page *src)
>>   #define hugetlb_change_protection(vma, address, end, newprot)
>>
>>   #ifndef HPAGE_MASK
>> -#define HPAGE_MASK	PAGE_MASK		/* Keep the compiler happy */
>> -#define HPAGE_SIZE	PAGE_SIZE
>> +/* Keep the compiler happy with some dummy (but BUGgy) values */
>
> That's a quite poor comment.  This?

I was trying to communicate the presence of the BUG() in the definition. 
  Perhaps it is more confusing than it was before.

>
> --- a/include/linux/hugetlb.h~hugetlb-provide-safer-dummy-values-for-hpage_mask-and-hpage_size-fix
> +++ a/include/linux/hugetlb.h
> @@ -111,7 +111,11 @@ static inline void copy_huge_page(struct
>   #define hugetlb_change_protection(vma, address, end, newprot)
>
>   #ifndef HPAGE_MASK
> -/* Keep the compiler happy with some dummy (but BUGgy) values */
> +/*
> + * HPAGE_MASK and friends are defined if !CONFIG_HUGETLB_PAGE as an
> + * ifdef-avoiding convenience.  However they should never be evaluated at
> + * runtime if !CONFIG_HUGETLB_PAGE.
> + */
>   #define HPAGE_MASK	({BUG(); 0; })
>   #define HPAGE_SIZE	({BUG(); 0; })
>   #define HPAGE_SHIFT	({BUG(); 0; })
> _
>
>> +#define HPAGE_MASK	({BUG(); 0; })
>> +#define HPAGE_SIZE	({BUG(); 0; })
>>   #define HPAGE_SHIFT	({BUG(); 0; })
>
> This change means that HPAGE_* cannot be evaluated at compile time.  So
>
> int foo = HPAGE_SIZE;
>
> outside functions will explode.  I guess that's OK - actually desirable
> - as such code shouldn't have been compiled anyway.
>

The exact point of the patch.

Thanks,
David Daney



  reply	other threads:[~2011-11-17 23:38 UTC|newest]

Thread overview: 26+ 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 [this message]
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-21 23:47         ` David Daney
2011-11-21 23:53           ` Andrew Morton
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=4EC59B02.7060804@gmail.com \
    --to=ddaney.cavm@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=david.daney@cavium.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=rientjes@google.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).