Re : vm: weird behaviour when munmapping

Re : vm: weird behaviour when munmapping

[moreau francis]

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 ?

Francis






	

	
		
___________________________________________________________________________ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com

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.

Re : vm: weird behaviour when munmapping

[Francis Moreau]

[me moving to Gmail 'cause yahoo sucks !]

On Fri, 2006-11-17 at 14:12 +0000, moreau francis wrote:
> Peter Zijlstra wrote:
>
> The new object is the one allocated using:
>	new = kmem_cache_alloc(vm_area_cachep, SLAB_KERNEL);
>

Of course but at this point the choice of the new VMA is already made
by the caller. So in our case do_munmap() decided that B is the new
one as you said. But I still don't see why...

And as I said previously it will end up by calling consecutively:

        vma->vm_ops->open(B)
        vma->vm_ops->close(B)


> Please read Mel Gorman's book on memory management to gain a better
> understanding.
>
> http://www.phptr.com/bookstore/product.asp?isbn=0131453483&rl=1

thanks for the link, but I don't expect to find out the answer to this
very specific question in it.

Francis

Re: Re : vm: weird behaviour when munmapping

[Hugh Dickins]

On Fri, 17 Nov 2006, Francis Moreau wrote:
> On Fri, 2006-11-17 at 14:12 +0000, moreau francis wrote:
> > Peter Zijlstra wrote:
> >
> > The new object is the one allocated using:
> > new = kmem_cache_alloc(vm_area_cachep, SLAB_KERNEL);
> 
> Of course but at this point the choice of the new VMA is already made
> by the caller. So in our case do_munmap() decided that B is the new
> one as you said. But I still don't see why...

split_vma decides which address range will use the newly allocated
vm_area_struct in such a way as to suit its own convenience, and
that of mremap's move_vma.  "new" is the name of a variable in
split_vma, you should stop agonizing over it.

> 
> And as I said previously it will end up by calling consecutively:
> 
>        vma->vm_ops->open(B)
>        vma->vm_ops->close(B)

You are attaching too much significance to the current address
of the vma which is passed to your driver in open and close.
As mmap.c splits and merges vmas, in response to system calls
unmapping and mapping, those addresses will change.

The important thing is the info contained within the vma: perhaps
your underlying complaint is that your driver is not getting as
much info as it wants about what's happening?

I think (haven't searched) most drivers, if they care at all,
only care about the total number of their vmas: can free
resources when that count goes down to 0.

Hugh

Re: Re : vm: weird behaviour when munmapping

[Francis Moreau]

On 11/18/06, Hugh Dickins <hugh@veritas.com> wrote:
> On Fri, 17 Nov 2006, Francis Moreau wrote:
> > On Fri, 2006-11-17 at 14:12 +0000, moreau francis wrote:
> > > Peter Zijlstra wrote:
> > >
> > > The new object is the one allocated using:
> > > new = kmem_cache_alloc(vm_area_cachep, SLAB_KERNEL);
> >
> > Of course but at this point the choice of the new VMA is already made
> > by the caller. So in our case do_munmap() decided that B is the new
> > one as you said. But I still don't see why...
>
> split_vma decides which address range will use the newly allocated
> vm_area_struct in such a way as to suit its own convenience, and

again I don't agree. I would say that do_munmap() decides which
address range will use the new allocated vma object. split_vma() get
this information through its parameter named "new_below".

> >
> > And as I said previously it will end up by calling consecutively:
> >
> >        vma->vm_ops->open(B)
> >        vma->vm_ops->close(B)
>
> You are attaching too much significance to the current address
> of the vma which is passed to your driver in open and close.
> As mmap.c splits and merges vmas, in response to system calls
> unmapping and mapping, those addresses will change.
>
> The important thing is the info contained within the vma: perhaps
> your underlying complaint is that your driver is not getting as
> much info as it wants about what's happening?
>

not really. I'm not writing a real driver. I just try to understand
how vma things work in Linux. Therefore I just wrote a dumb driver
which has modified vma open/close method in order to detect how these
method are called.

I end up to see "open(B), close(B)" sequence when unmapping a part of
the dumb device that I found strange. I think that "open(A') close(B)"
can give more information to the driver and reflect that B is unmapped
and A' is still mapped and becomes the new mapped area.
But it's may be just me...

thanks

Francis

Re: Re : vm: weird behaviour when munmapping

[Hugh Dickins]

On Mon, 20 Nov 2006, Francis Moreau wrote:
> On 11/18/06, Hugh Dickins <hugh@veritas.com> wrote:
> >
> > split_vma decides which address range will use the newly allocated
> > vm_area_struct in such a way as to suit its own convenience, and
> 
> again I don't agree. I would say that do_munmap() decides which
> address range will use the new allocated vma object. split_vma() get
> this information through its parameter named "new_below".

Yes, you're right.

Hugh

Re: Re : vm: weird behaviour when munmapping

[Hugh Dickins]

On Mon, 20 Nov 2006, Francis Moreau wrote:
> 
> I end up to see "open(B), close(B)" sequence when unmapping a part of
> the dumb device that I found strange. I think that "open(A') close(B)"
> can give more information to the driver and reflect that B is unmapped
> and A' is still mapped and becomes the new mapped area.
> But it's may be just me...

I think I do now get your point.  But your way round doesn't really
reflect what's going on either: the range A' was already open and now
you open it again.  Until there's some driver actually needing more
sophisticated treatment, let's just leave it the simple way it is.

Hugh

Re: Re : vm: weird behaviour when munmapping

[Francis Moreau]

On 11/20/06, Hugh Dickins <hugh@veritas.com> wrote:
> On Mon, 20 Nov 2006, Francis Moreau wrote:
> >
> > I end up to see "open(B), close(B)" sequence when unmapping a part of
> > the dumb device that I found strange. I think that "open(A') close(B)"
> > can give more information to the driver and reflect that B is unmapped
> > and A' is still mapped and becomes the new mapped area.
> > But it's may be just me...
>
> I think I do now get your point.  But your way round doesn't really

my fault, I think I wasn't very clear when explaining myself

> reflect what's going on either: the range A' was already open and now
> you open it again.  Until there's some driver actually needing more
> sophisticated treatment, let's just leave it the simple way it is.

Yes, I agree that both ways are not satisfacting. Maybe having
vma->resize() method would have been better, I dunno.

Anyways thanks for your answers.
-- 
Francis

Re : vm: weird behaviour when munmapping

[moreau francis]

Peter Zijlstra wrote:
> 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.

Is there any rules to decide which VMA is the new one ? 

>From what you wrote it seems that we call B the new object because
it has a new end address...

>From my point of view, I called B the old VMA simply because it's
going to be destroyed...

Francis





	

	
		
___________________________________________________________________________ 
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com

Re: Re : vm: weird behaviour when munmapping

[Peter Zijlstra]

On Fri, 2006-11-17 at 14:12 +0000, moreau francis wrote:
> Peter Zijlstra wrote:
> > 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.
> 
> Is there any rules to decide which VMA is the new one ? 

The new object is the one allocated using:
	new = kmem_cache_alloc(vm_area_cachep, SLAB_KERNEL);

> From what you wrote it seems that we call B the new object because
> it has a new end address...

No, because its newly allocated.

> From my point of view, I called B the old VMA simply because it's
> going to be destroyed...

Please read Mel Gorman's book on memory management to gain a better
understanding.

http://www.phptr.com/bookstore/product.asp?isbn=0131453483&rl=1

Re : vm: weird behaviour when munmapping

[moreau francis]

Peter Zijlstra wrote:
> 
> http://lwn.net/Kernel/LDD3/
> 
> Chapter 15. Section 'Virtual Memory Areas'.
> 
> Basically; vm_ops->open() is not called on the first vma. With this
> munmap() you split the area in two, and it so happens the new vma is the
> lower one.
> 

since I did "munmap(0x2aaae000, 1024)" I would say that the the new vma
is the _upper_ one.

lower vma: 0x2aaae000 -> 0x2aaaf000
upper vma: 0x2aaaf000 -> 0x2aab2000

Francis







	

	
		
___________________________________________________________________________ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com

Re: Re : vm: weird behaviour when munmapping

[Peter Zijlstra]

On Fri, 2006-11-17 at 12:50 +0000, moreau francis wrote:
> Peter Zijlstra wrote:
> > 
> > http://lwn.net/Kernel/LDD3/
> > 
> > Chapter 15. Section 'Virtual Memory Areas'.
> > 
> > Basically; vm_ops->open() is not called on the first vma. With this
> > munmap() you split the area in two, and it so happens the new vma is the
> > lower one.
> > 
> 
> since I did "munmap(0x2aaae000, 1024)" I would say that the the new vma
> is the _upper_ one.
> 
> 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.