Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1603655 > unrolled thread
| Started by | Richard Weinberger <richard@nod.at> |
|---|---|
| First post | 2017-03-18 00:20 +0100 |
| Last post | 2017-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.
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
| From | Richard Weinberger <richard@nod.at> |
|---|---|
| Date | 2017-03-18 00:20 +0100 |
| Subject | Re: 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
Back to top | Article view | linux.kernel
csiph-web