Re: Re : vm: weird behaviour when munmapping

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/18/06, Hugh Dickins <[email protected]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux