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 <[email protected]>
> AuthorDate: Wed Jun 15 15:08:11 2011 -0700
> Committer: Linus Torvalds <[email protected]>
> 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 <[email protected]>
> Cc: Mel Gorman <[email protected]>
> Signed-off-by: Andrew Morton <[email protected]>
> Signed-off-by: Linus Torvalds <[email protected]>
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 ***
On Wed, Jun 15, 2011 at 9:35 PM, Randy Dunlap <[email protected]> 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
On Wed, 15 Jun 2011 21:45:00 -0700 Linus Torvalds <[email protected]> wrote:
> On Wed, Jun 15, 2011 at 9:35 PM, Randy Dunlap <[email protected]> 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 <[email protected]>
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 <[email protected]>
Cc: Mel Gorman <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
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;
_
On Wed 15-06-11 21:52:07, Andrew Morton wrote:
> On Wed, 15 Jun 2011 21:45:00 -0700 Linus Torvalds <[email protected]> wrote:
>
> > On Wed, Jun 15, 2011 at 9:35 PM, Randy Dunlap <[email protected]> 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
On Wed, 15 Jun 2011 21:52:07 -0700, Andrew Morton
<[email protected]> wrote:
> On Wed, 15 Jun 2011 21:45:00 -0700 Linus Torvalds
> <[email protected]> wrote:
>
>> On Wed, Jun 15, 2011 at 9:35 PM, Randy Dunlap <[email protected]> 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