Re: fs/exec.c: use BUILD_BUG_ON for VM_STACK_FLAGS & VM_STACK_INCOMPLETE_SETUP

Re: fs/exec.c: use BUILD_BUG_ON for VM_STACK_FLAGS & VM_STACK_INCOMPLETE_SETUP

[Randy Dunlap]

On Thu, 16 Jun 2011 03:59:03 GMT Linux Kernel Mailing List wrote:

> Gitweb:     http://git.kernel.org/linus/7f81c8890c15a10f5220bebae3b6dfae4961962a
> Commit:     7f81c8890c15a10f5220bebae3b6dfae4961962a
> Parent:     b0825ee3a8c570df4873ee397fa453e67fdad5d7
> Author:     Michal Hocko <mhocko@suse.cz>
> AuthorDate: Wed Jun 15 15:08:11 2011 -0700
> Committer:  Linus Torvalds <torvalds@linux-foundation.org>
> CommitDate: Wed Jun 15 20:03:59 2011 -0700
> 
>     fs/exec.c: use BUILD_BUG_ON for VM_STACK_FLAGS & VM_STACK_INCOMPLETE_SETUP
>     
>     Commit a8bef8ff6ea1 ("mm: migration: avoid race between shift_arg_pages()
>     and rmap_walk() during migration by not migrating temporary stacks")
>     introduced a BUG_ON() to ensure that VM_STACK_FLAGS and
>     VM_STACK_INCOMPLETE_SETUP do not overlap.  The check is a compile time
>     one, so BUILD_BUG_ON is more appropriate.
>     
>     Signed-off-by: Michal Hocko <mhocko@suse.cz>
>     Cc: Mel Gorman <mel@csn.ul.ie>
>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

fwiw, I just reported that this causes a build error in UML on x86_64
in mmotm-2011-06-15:

When building UML for x86_64 (defconfig), I get:

fs/built-in.o: In function `__bprm_mm_init':
mmotm-2011-0615-1656/fs/exec.c:280: undefined reference to `__build_bug_on_failed'


> ---
>  fs/exec.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/fs/exec.c b/fs/exec.c
> index 97e0d52..b54f74f 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -277,7 +277,7 @@ static int __bprm_mm_init(struct linux_binprm *bprm)
>  	 * use STACK_TOP because that can depend on attributes which aren't
>  	 * configured yet.
>  	 */
> -	BUG_ON(VM_STACK_FLAGS & VM_STACK_INCOMPLETE_SETUP);
> +	BUILD_BUG_ON(VM_STACK_FLAGS & VM_STACK_INCOMPLETE_SETUP);
>  	vma->vm_end = STACK_TOP_MAX;
>  	vma->vm_start = vma->vm_end - PAGE_SIZE;
>  	vma->vm_flags = VM_STACK_FLAGS | VM_STACK_INCOMPLETE_SETUP;
> --


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: fs/exec.c: use BUILD_BUG_ON for VM_STACK_FLAGS & VM_STACK_INCOMPLETE_SETUP

[Linus Torvalds]

On Wed, Jun 15, 2011 at 9:35 PM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
>
> fwiw, I just reported that this causes a build error in UML on x86_64
> in mmotm-2011-06-15:

Gaah. That sounds really familiar. Have we done this same mistake once
before already, or is it just deja-vu for some other reason.

On x86-64 UML, we have

  #define VM_STACK_DEFAULT_FLAGS vm_stack_flags

so VM_STACK_FLAGS ends up not being a constant, even though it really
looks like one.

UML is _really_ confused in this area, btw. It seems to re-define that
thing if TIF_IA32 is defined. That's some crazy stuff. Doesn't the
compiler warn about it?

I guess I should just revert that commit, though. Even if it does seem
to be the case that UML is just being crazy. Andrew?

                  Linus

Re: fs/exec.c: use BUILD_BUG_ON for VM_STACK_FLAGS & VM_STACK_INCOMPLETE_SETUP

[Andrew Morton]

On Wed, 15 Jun 2011 21:45:00 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Wed, Jun 15, 2011 at 9:35 PM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> >
> > fwiw, I just reported that this causes a build error in UML on x86_64
> > in mmotm-2011-06-15:
> 
> Gaah. That sounds really familiar. Have we done this same mistake once
> before already, or is it just deja-vu for some other reason.
> 
> On x86-64 UML, we have
> 
>   #define VM_STACK_DEFAULT_FLAGS vm_stack_flags
> 
> so VM_STACK_FLAGS ends up not being a constant, even though it really
> looks like one.
> 
> UML is _really_ confused in this area, btw. It seems to re-define that
> thing if TIF_IA32 is defined. That's some crazy stuff. Doesn't the
> compiler warn about it?
> 
> I guess I should just revert that commit, though. Even if it does seem
> to be the case that UML is just being crazy. Andrew?
> 

Sure, it was just a tiny optimization.

We can bring it back if Richard feels like decrazyifying UML ;)



From: Michal Hocko <mhocko@suse.cz>

a8bef8ff ("mm: migration: avoid race between shift_arg_pages() and
rmap_walk() during migration by not migrating temporary stacks")
introduced a BUG_ON() to ensure that VM_STACK_FLAGS and
VM_STACK_INCOMPLETE_SETUP do not overlap.  The check is a compile time
one, so BUILD_BUG_ON is more appropriate.

Signed-off-by: Michal Hocko <mhocko@suse.cz>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 fs/exec.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -puN fs/exec.c~fs-execc-use-build_bug_on-for-vm_stack_flags-vm_stack_incomplete_setup fs/exec.c
--- a/fs/exec.c~fs-execc-use-build_bug_on-for-vm_stack_flags-vm_stack_incomplete_setup
+++ a/fs/exec.c
@@ -277,7 +277,7 @@ static int __bprm_mm_init(struct linux_b
 	 * use STACK_TOP because that can depend on attributes which aren't
 	 * configured yet.
 	 */
-	BUG_ON(VM_STACK_FLAGS & VM_STACK_INCOMPLETE_SETUP);
+	BUILD_BUG_ON(VM_STACK_FLAGS & VM_STACK_INCOMPLETE_SETUP);
 	vma->vm_end = STACK_TOP_MAX;
 	vma->vm_start = vma->vm_end - PAGE_SIZE;
 	vma->vm_flags = VM_STACK_FLAGS | VM_STACK_INCOMPLETE_SETUP;
_

Re: fs/exec.c: use BUILD_BUG_ON for VM_STACK_FLAGS & VM_STACK_INCOMPLETE_SETUP

[Michal Hocko]

On Wed 15-06-11 21:52:07, Andrew Morton wrote:
> On Wed, 15 Jun 2011 21:45:00 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > On Wed, Jun 15, 2011 at 9:35 PM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > >
> > > fwiw, I just reported that this causes a build error in UML on x86_64
> > > in mmotm-2011-06-15:
> > 
> > Gaah. That sounds really familiar. Have we done this same mistake once
> > before already, or is it just deja-vu for some other reason.
> > 
> > On x86-64 UML, we have
> > 
> >   #define VM_STACK_DEFAULT_FLAGS vm_stack_flags
> > 
> > so VM_STACK_FLAGS ends up not being a constant, even though it really
> > looks like one.
> > 
> > UML is _really_ confused in this area, btw. It seems to re-define that
> > thing if TIF_IA32 is defined. That's some crazy stuff. Doesn't the
> > compiler warn about it?
> > 
> > I guess I should just revert that commit, though. Even if it does seem
> > to be the case that UML is just being crazy. Andrew?
> > 
> 
> Sure, it was just a tiny optimization.

Please revert and sorry for this.

-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

Re: fs/exec.c: use BUILD_BUG_ON for VM_STACK_FLAGS & VM_STACK_INCOMPLETE_SETUP

[Richard Weinberger]

On Wed, 15 Jun 2011 21:52:07 -0700, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Wed, 15 Jun 2011 21:45:00 -0700 Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> 
>> On Wed, Jun 15, 2011 at 9:35 PM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
>> >
>> > fwiw, I just reported that this causes a build error in UML on x86_64
>> > in mmotm-2011-06-15:
>>
>> Gaah. That sounds really familiar. Have we done this same mistake once
>> before already, or is it just deja-vu for some other reason.
>>
>> On x86-64 UML, we have
>>
>>   #define VM_STACK_DEFAULT_FLAGS vm_stack_flags
>>
>> so VM_STACK_FLAGS ends up not being a constant, even though it really
>> looks like one.
>>
>> UML is _really_ confused in this area, btw. It seems to re-define that
>> thing if TIF_IA32 is defined. That's some crazy stuff. Doesn't the
>> compiler warn about it?
>>
>> I guess I should just revert that commit, though. Even if it does seem
>> to be the case that UML is just being crazy. Andrew?
>>
> 
> Sure, it was just a tiny optimization.
> 
> We can bring it back if Richard feels like decrazyifying UML ;)
> 

I'll look at this.
BTW: 64bit UML is really crazy. :P

Thanks,
//richard