Re: Re : vm: weird behaviour when munmapping

[Peter Zijlstra]

On Fri, 2006-11-17 at 13:43 +0000, moreau francis wrote:
> Peter Zijlstra wrote:
> > On Fri, 2006-11-17 at 12:50 +0000, moreau francis wrote:
> >>
> >> lower vma: 0x2aaae000 -> 0x2aaaf000
> >> upper vma: 0x2aaaf000 -> 0x2aab2000
> > 
> > that is the remaining VMA, not the new one; we trigger this code:
> > 
> >     /* Does it split the last one? */
> >     last = find_vma(mm, end);
> >     if (last && end > last->vm_start) {
> >         int error = split_vma(mm, last, end, 1);
> >         if (error)
> >             return error;
> >     }
> > 
> > So, since its the last VMA that needs to be split (there is only one),
> > the new VMA is constructed before the old one. Like so:
> > 
> >   AAAAAAAAAAAAAAAAAAAAA
> >   BBBBAAAAAAAAAAAAAAAAA
> > 
> > Then you proceed closing, in this case the new one: B.
> 
> Sorry but I don't understand why B is said to be the new one. OK
> I can see why from the bit of code you pointed out but from a
> logical point of view (ok maybe be me only) I'm unmapping 'BBBB'
> segment, so 'BBBB' is going to be destroyed and therefore A is
> the new one. Thereferore I would expect close(B), open(A)...
> 
> no ?

No indeed. You seem confused with remaining and new. 

It has one VMA (A) it needs to split that into two pieces, it happens to
do it like (B,A') where A' is the old VMA object with new a start
address, and B is a new VMA object.

If you'd unmapped the tail end of your region you'd then see a close of
A' but you happen to unmap the head so you'll see B closed.

vm_ops->open() is called on new VMA objects, in this scenario B is the
only new object created. A -> A' is not creating a new object just
modifying an old one.

-
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/