lkml.org 
[lkml]   [2009]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Fix OOPS in mmap_region() when merging adjacent VM_LOCKED file segments

On Fri, 30 Jan 2009, Lee Schermerhorn wrote:
>
> I just verified that adding VM_ACCOUNT to VM_MERGEABLE does allow the
> merge to happen with the test program. And the system didn't come
> crashing down around me. But, I wouldn't trust that simple test as the
> last word. A short run of a stress load I use held up/still running,
> but I can't tell whether it's merging as expected there.

Just ignoring VM_ACCOUNT for merging is not the right thing to do. It
probably works in practice for just about everything, but at least in
theory it does mean that mmap() can stop honoring MAP_NORESERVE.

Admittedly the circumstances where that happens are unlikely, and nobody
probably even really uses MAP_NORESERVE in the first place, so I doubt you
can ever see it as a real issue, but it's still technically wrong to merge
vma's that can differ in VM_ACCOUNT.

Now, the particular test you have, VM_ACCOUNT differs only during that
temporary window, and the vma's really do end up with the same VM_ACCOUNT
state in the end, so merging them is correct, but if you were to privately
map the same file (or private anonymous map) with the same permissions
next to each other so that they -could- merge, but use MAP_NORESERVE on
one and not on the other, then they shouldn't merge.

So VM_ACCOUNT does matter - just barely - for merging, and we just happen
to currently hit it too much due to a very odd internal reason.

Linus


\
 
 \ /
  Last update: 2009-01-30 23:31    [W:0.109 / U:0.916 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site