Re: Re : vm: weird behaviour when munmapping

[Hugh Dickins <hugh@veritas.com>]

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