Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1603655 > unrolled thread

Re: WARNING: CPU: 0 PID: 1 at mm/mmap.c:1110 vma_merge+0x9a/0x2c8

Started byRichard Weinberger <richard@nod.at>
First post2017-03-18 00:20 +0100
Last post2017-03-18 00:20 +0100
Articles 1 — 1 participant

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: WARNING: CPU: 0 PID: 1 at mm/mmap.c:1110 vma_merge+0x9a/0x2c8 Richard Weinberger <richard@nod.at> - 2017-03-18 00:20 +0100

#1603655 — Re: WARNING: CPU: 0 PID: 1 at mm/mmap.c:1110 vma_merge+0x9a/0x2c8

FromRichard Weinberger <richard@nod.at>
Date2017-03-18 00:20 +0100
SubjectRe: WARNING: CPU: 0 PID: 1 at mm/mmap.c:1110 vma_merge+0x9a/0x2c8
Message-ID<tm9k5-5I7-3@gated-at.bofh.it>
[re-sending with mailinglists]

Andrea,

Am 17.03.2017 um 19:36 schrieb Andrea Arcangeli:
> I think the problem is in setup_arg_pages that is making an assumption
> non true in UML (and only UML) case, i.e. that there are no vmas below
> bprm->vma by the time mprotect_fixup is executed. That is not the case
> for UML as you likely installed vmas below bprm->vma before calling
> mprotect_fixup in setup_arg_pages. The fix should be just to change
> setup_arg_pages to find the correct "prev" vma, then this code will
> pick "area" as prev->vm_next which is bprm->vma as expected:
> 
> 	if (prev)
> 		next = prev->vm_next;
> 	else
> 		next = mm->mmap;
> 	area = next;
> 
> *prev == NULL tells vma_merge that the only vma that there is is
> mm->mmap so it uses that as "area" but for you mm->mmap is prev or
> prev->prev or something like that, not the "area". To make it find the
> right area you need to pass the right *prev to mprotect_fixup if there
> are real "prev" vmas not just bprm->vma instantiated.

I think you are right, thanks for the great explanation!

UML installs this vma very early and as of now I'm not sure why we can't
install it a bit later just like we do for the vDSO.
So far it did not explode. :)
This solution would be better than finding a pre-existing vma before
calling mprotect_fixup().

Thanks,
//richard

[toc] | [standalone]


Back to top | Article view | linux.kernel


csiph-web