Re: Possible regression from "fs/exec.c: call arch_pick_mmap_layout()only once"

[Pat Erley]

On 01/02/2014 04:39 PM, Pat Erley wrote:
> On 01/02/2014 04:24 PM, Richard Weinberger wrote:
> > Am Donnerstag, 2. Januar 2014, 15:41:27 schrieb Pat Erley:
> > > On my 64bit kernel, commit 283fe963095b38a6ab75dda1436ee66b9e45c7c2
> > > seems to have broken 32bit compatibility.  I've run the bisection twice,
> > > and verified that reverting this on HEAD fixes the problem.  I've
> > > uploaded my .config to pastebin at http://pastebin.com/kVcr9H65
> > >
> > > Even this simple program:
> > >
> > > main(){puts("HELLO");}
> > >
> > > compiled with:
> > >
> > > gcc -m32 test.c
> > >
> > > Will crash with a segfault.  Stracing shows that it's failing to
> > > allocate memory.
> >
> > Good catch!
> >
> > flush_old_exec() is called before setup_new_exec() and I've removed
> > arch_pick_mmap_layout() from the second call site.
> > Which turned out to be wrong.
> >
> > It is wrong because between both callers current->personality is changed.
> > So, we have to remove the first call to arch_pick_mmap_layout() and
> > keep the
> > latter because only then the correct personality is set up.
> >
> > Can you please test your config with the following patch applied and
> > having
> > 283fe96 reverted?
> >
> > If it works out for you I'd send an updated patch to Andrew.
> > In the meanwhile I'll double check all call sites...
> >
> > Thanks,
> > //richard
> >
> > ---
> > diff --git a/fs/exec.c b/fs/exec.c
> > index 7ea097f..a733599 100644
> > --- a/fs/exec.c
> > +++ b/fs/exec.c
> > @@ -843,7 +843,6 @@ static int exec_mmap(struct mm_struct *mm)
> >       tsk->active_mm = mm;
> >       activate_mm(active_mm, mm);
> >       task_unlock(tsk);
> > -    arch_pick_mmap_layout(mm);
> >       if (old_mm) {
> >           up_read(&old_mm->mmap_sem);
> >           BUG_ON(active_mm != old_mm);
>
> Compiling right now.  Will test later tonight and let you know.
>
> Pat

I can confirm that this works with 283fe96 reverted.

Pat

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/