* Re: fs/exec.c: use BUILD_BUG_ON for VM_STACK_FLAGS & VM_STACK_INCOMPLETE_SETUP [not found] <201106160359.p5G3x3j4020081@hera.kernel.org> @ 2011-06-16 4:35 ` Randy Dunlap 2011-06-16 4:45 ` Linus Torvalds 0 siblings, 1 reply; 5+ messages in thread From: Randy Dunlap @ 2011-06-16 4:35 UTC (permalink / raw) To: Linux Kernel Mailing List, akpm; +Cc: torvalds, Michal Hocko 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 *** ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: fs/exec.c: use BUILD_BUG_ON for VM_STACK_FLAGS & VM_STACK_INCOMPLETE_SETUP 2011-06-16 4:35 ` fs/exec.c: use BUILD_BUG_ON for VM_STACK_FLAGS & VM_STACK_INCOMPLETE_SETUP Randy Dunlap @ 2011-06-16 4:45 ` Linus Torvalds 2011-06-16 4:52 ` Andrew Morton 0 siblings, 1 reply; 5+ messages in thread From: Linus Torvalds @ 2011-06-16 4:45 UTC (permalink / raw) To: Randy Dunlap; +Cc: Linux Kernel Mailing List, akpm, Michal Hocko 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: fs/exec.c: use BUILD_BUG_ON for VM_STACK_FLAGS & VM_STACK_INCOMPLETE_SETUP 2011-06-16 4:45 ` Linus Torvalds @ 2011-06-16 4:52 ` Andrew Morton 2011-06-16 6:35 ` Michal Hocko 2011-06-16 9:36 ` Richard Weinberger 0 siblings, 2 replies; 5+ messages in thread From: Andrew Morton @ 2011-06-16 4:52 UTC (permalink / raw) To: Linus Torvalds Cc: Randy Dunlap, Linux Kernel Mailing List, Michal Hocko, Richard Weinberger 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; _ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: fs/exec.c: use BUILD_BUG_ON for VM_STACK_FLAGS & VM_STACK_INCOMPLETE_SETUP 2011-06-16 4:52 ` Andrew Morton @ 2011-06-16 6:35 ` Michal Hocko 2011-06-16 9:36 ` Richard Weinberger 1 sibling, 0 replies; 5+ messages in thread From: Michal Hocko @ 2011-06-16 6:35 UTC (permalink / raw) To: Linus Torvalds Cc: Andrew Morton, Randy Dunlap, Linux Kernel Mailing List, Richard Weinberger 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: fs/exec.c: use BUILD_BUG_ON for VM_STACK_FLAGS & VM_STACK_INCOMPLETE_SETUP 2011-06-16 4:52 ` Andrew Morton 2011-06-16 6:35 ` Michal Hocko @ 2011-06-16 9:36 ` Richard Weinberger 1 sibling, 0 replies; 5+ messages in thread From: Richard Weinberger @ 2011-06-16 9:36 UTC (permalink / raw) To: Andrew Morton Cc: Linus Torvalds, Randy Dunlap, Linux Kernel Mailing List, Michal Hocko 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-06-16 9:36 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <201106160359.p5G3x3j4020081@hera.kernel.org>
2011-06-16 4:35 ` fs/exec.c: use BUILD_BUG_ON for VM_STACK_FLAGS & VM_STACK_INCOMPLETE_SETUP Randy Dunlap
2011-06-16 4:45 ` Linus Torvalds
2011-06-16 4:52 ` Andrew Morton
2011-06-16 6:35 ` Michal Hocko
2011-06-16 9:36 ` Richard Weinberger
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox