From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42])
	by kanga.kvack.org (Postfix) with ESMTP id E97D76B0032
	for <linux-mm@kvack.org>; Sat, 28 Feb 2015 01:47:18 -0500 (EST)
Received: by pabrd3 with SMTP id rd3so28407732pab.1
        for <linux-mm@kvack.org>; Fri, 27 Feb 2015 22:47:18 -0800 (PST)
Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com. [2607:f8b0:400e:c02::22e])
        by mx.google.com with ESMTPS id q15si8100020pdl.247.2015.02.27.22.47.17
        for <linux-mm@kvack.org>
        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 27 Feb 2015 22:47:18 -0800 (PST)
Received: by pdbfp1 with SMTP id fp1so26198063pdb.9
        for <linux-mm@kvack.org>; Fri, 27 Feb 2015 22:47:17 -0800 (PST)
Date: Sat, 28 Feb 2015 14:46:47 +0800
From: Wang YanQing <udknight@gmail.com>
Subject: [RFC] Strange do_munmap in mmap_region
Message-ID: <20150228064647.GA9550@udknight.ahead-top.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-linux-mm@kvack.org
List-ID: <linux-mm.kvack.org>
To: mgorman@suse.de
Cc: linux-mm@kvack.org, yinghai@kernel.org.ahead-top.com, akpm@linux-foundation.org

Hi Mel Gorman and all.

I have read do_mmap_pgoff and mmap_region more than one hour,
but still can't catch sense about below code in mmap_region:

"
        /* Clear old maps */
        error = -ENOMEM;
munmap_back:
        if (find_vma_links(mm, addr, addr + len, &prev, &rb_link, &rb_parent)) {
                if (do_munmap(mm, addr, len))
                        return -ENOMEM;
                goto munmap_back;
        }
"

How can we just do_munmap overlapping vma without check its vm_flags
and new vma's vm_flags? I must miss some important things, but I can't
figure out.

You give below comment about the code in "understand the linux memory manager":)

"
If a VMA was found and it is part of the new mmapping, this removes the
 old mmapping because the new one will cover both 
"

But if new mmapping has different vm_flags or others' property, how
can we just say the new one will cover both?

I appreicate any clue and explanation about this headache question.

Thanks.






--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51])
	by kanga.kvack.org (Postfix) with ESMTP id BA2CD6B0038
	for <linux-mm@kvack.org>; Thu, 19 Mar 2015 04:33:43 -0400 (EDT)
Received: by ladw1 with SMTP id w1so56068154lad.0
        for <linux-mm@kvack.org>; Thu, 19 Mar 2015 01:33:43 -0700 (PDT)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com. [2a00:1450:4010:c03::231])
        by mx.google.com with ESMTPS id i9si474269lae.58.2015.03.19.01.33.41
        for <linux-mm@kvack.org>
        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 19 Mar 2015 01:33:41 -0700 (PDT)
Received: by labjg1 with SMTP id jg1so56076568lab.2
        for <linux-mm@kvack.org>; Thu, 19 Mar 2015 01:33:41 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <20150228064647.GA9550@udknight.ahead-top.com>
References: <20150228064647.GA9550@udknight.ahead-top.com>
Date: Thu, 19 Mar 2015 11:33:41 +0300
Message-ID: <CALYGNiMLwhqQSmj58mT4MWk2RAuU-3TykoSd=XjuXVfqkL3NoA@mail.gmail.com>
Subject: Re: [RFC] Strange do_munmap in mmap_region
From: Konstantin Khlebnikov <koct9i@gmail.com>
Content-Type: text/plain; charset=UTF-8
Sender: owner-linux-mm@kvack.org
List-ID: <linux-mm.kvack.org>
To: Wang YanQing <udknight@gmail.com>
Cc: Mel Gorman <mgorman@suse.de>, "linux-mm@kvack.org" <linux-mm@kvack.org>, yinghai@kernel.org.ahead-top.com, Andrew Morton <akpm@linux-foundation.org>

On Sat, Feb 28, 2015 at 9:46 AM, Wang YanQing <udknight@gmail.com> wrote:
> Hi Mel Gorman and all.
>
> I have read do_mmap_pgoff and mmap_region more than one hour,
> but still can't catch sense about below code in mmap_region:
>
> "
>         /* Clear old maps */
>         error = -ENOMEM;
> munmap_back:
>         if (find_vma_links(mm, addr, addr + len, &prev, &rb_link, &rb_parent)) {
>                 if (do_munmap(mm, addr, len))
>                         return -ENOMEM;
>                 goto munmap_back;
>         }
> "
>
> How can we just do_munmap overlapping vma without check its vm_flags
> and new vma's vm_flags? I must miss some important things, but I can't
> figure out.
>
> You give below comment about the code in "understand the linux memory manager":)
>
> "
> If a VMA was found and it is part of the new mmapping, this removes the
>  old mmapping because the new one will cover both
> "
>
> But if new mmapping has different vm_flags or others' property, how
> can we just say the new one will cover both?
>
> I appreicate any clue and explanation about this headache question.
>
> Thanks.
>

Mmap() creates new mapping in given range
(new vma might be merged to one or both of sides if possible)
so everything what was here before is unmapped in process. Not?

>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47])
	by kanga.kvack.org (Postfix) with ESMTP id 1D9326B0038
	for <linux-mm@kvack.org>; Thu, 19 Mar 2015 11:20:19 -0400 (EDT)
Received: by pacwe9 with SMTP id we9so78506368pac.1
        for <linux-mm@kvack.org>; Thu, 19 Mar 2015 08:20:18 -0700 (PDT)
Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com. [2607:f8b0:400e:c02::231])
        by mx.google.com with ESMTPS id ro12si3526447pab.108.2015.03.19.08.20.17
        for <linux-mm@kvack.org>
        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 19 Mar 2015 08:20:18 -0700 (PDT)
Received: by pdbni2 with SMTP id ni2so79154309pdb.1
        for <linux-mm@kvack.org>; Thu, 19 Mar 2015 08:20:17 -0700 (PDT)
Date: Thu, 19 Mar 2015 23:12:14 +0800
From: Wang YanQing <udknight@gmail.com>
Subject: Re: [RFC] Strange do_munmap in mmap_region
Message-ID: <20150319151214.GA2175@udknight>
References: <20150228064647.GA9550@udknight.ahead-top.com>
 <CALYGNiMLwhqQSmj58mT4MWk2RAuU-3TykoSd=XjuXVfqkL3NoA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALYGNiMLwhqQSmj58mT4MWk2RAuU-3TykoSd=XjuXVfqkL3NoA@mail.gmail.com>
Sender: owner-linux-mm@kvack.org
List-ID: <linux-mm.kvack.org>
To: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Mel Gorman <mgorman@suse.de>, "linux-mm@kvack.org" <linux-mm@kvack.org>, yinghai@kernel.org, Andrew Morton <akpm@linux-foundation.org>

On Thu, Mar 19, 2015 at 11:33:41AM +0300, Konstantin Khlebnikov wrote:
> On Sat, Feb 28, 2015 at 9:46 AM, Wang YanQing <udknight@gmail.com> wrote:
> > Hi Mel Gorman and all.
> >
> > I have read do_mmap_pgoff and mmap_region more than one hour,
> > but still can't catch sense about below code in mmap_region:
> >
> > "
> >         /* Clear old maps */
> >         error = -ENOMEM;
> > munmap_back:
> >         if (find_vma_links(mm, addr, addr + len, &prev, &rb_link, &rb_parent)) {
> >                 if (do_munmap(mm, addr, len))
> >                         return -ENOMEM;
> >                 goto munmap_back;
> >         }
> > "
> >
> > How can we just do_munmap overlapping vma without check its vm_flags
> > and new vma's vm_flags? I must miss some important things, but I can't
> > figure out.
> >
> > You give below comment about the code in "understand the linux memory manager":)
> >
> > "
> > If a VMA was found and it is part of the new mmapping, this removes the
> >  old mmapping because the new one will cover both
> > "
> >
> > But if new mmapping has different vm_flags or others' property, how
> > can we just say the new one will cover both?
> >
> > I appreicate any clue and explanation about this headache question.
> >
> > Thanks.
> >
> 
> Mmap() creates new mapping in given range
> (new vma might be merged to one or both of sides if possible)
> so everything what was here before is unmapped in process. Not?

Thanks for reply.

Assme process has vma in region 4096-8192, one page size, mapped to
a file's first 4096 bytes, then a new map want to create vma in range
0-8192 to map 4096-1288 in file, please tell me what's your meaning:
"so everything what was here before is unmapped in process"?

Why we can just delete old vma for first 4096 size in file which reside
in range 4096-8192 without notify user process? And create the new vma
to occupy range 0-8192, do you think "everything" is really the same?

Process lost old map for file's first 4096 bytes, and we use a new
map for 4096-1288 in file to lie it, and say "the same".

Indeed, I have another question, I guess the answer could save me the
same as this question.

I have read get_unmapped_area, it seems it will return a unused enough
region for new vma, and we hold mm->mmap_sem before vm_mmap_pgoff,
why unused enough region return by get_unmapped_area has overlapping vma
in mmap_region cause the first question?

I have tested it, running system always call do_munmap in mmap_region, so
I must miss something important, it is strange.

Thanks again.
> 
> >
> >
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
> > the body to majordomo@kvack.org.  For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45])
	by kanga.kvack.org (Postfix) with ESMTP id D9CE16B006E
	for <linux-mm@kvack.org>; Thu, 19 Mar 2015 11:36:56 -0400 (EDT)
Received: by lamx15 with SMTP id x15so65444244lam.3
        for <linux-mm@kvack.org>; Thu, 19 Mar 2015 08:36:56 -0700 (PDT)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com. [2a00:1450:4010:c03::235])
        by mx.google.com with ESMTPS id x16si1262610lbg.47.2015.03.19.08.36.54
        for <linux-mm@kvack.org>
        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 19 Mar 2015 08:36:55 -0700 (PDT)
Received: by ladw1 with SMTP id w1so65286285lad.0
        for <linux-mm@kvack.org>; Thu, 19 Mar 2015 08:36:54 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <20150319151214.GA2175@udknight>
References: <20150228064647.GA9550@udknight.ahead-top.com>
	<CALYGNiMLwhqQSmj58mT4MWk2RAuU-3TykoSd=XjuXVfqkL3NoA@mail.gmail.com>
	<20150319151214.GA2175@udknight>
Date: Thu, 19 Mar 2015 18:36:54 +0300
Message-ID: <CALYGNiPjEFLC2uiTGZMqP4TwDBit6+3VaiEpvGELYg8jDsVXBw@mail.gmail.com>
Subject: Re: [RFC] Strange do_munmap in mmap_region
From: Konstantin Khlebnikov <koct9i@gmail.com>
Content-Type: text/plain; charset=UTF-8
Sender: owner-linux-mm@kvack.org
List-ID: <linux-mm.kvack.org>
To: Wang YanQing <udknight@gmail.com>
Cc: Mel Gorman <mgorman@suse.de>, "linux-mm@kvack.org" <linux-mm@kvack.org>, yinghai@kernel.org, Andrew Morton <akpm@linux-foundation.org>

On Thu, Mar 19, 2015 at 6:12 PM, Wang YanQing <udknight@gmail.com> wrote:
> On Thu, Mar 19, 2015 at 11:33:41AM +0300, Konstantin Khlebnikov wrote:
>> On Sat, Feb 28, 2015 at 9:46 AM, Wang YanQing <udknight@gmail.com> wrote:
>> > Hi Mel Gorman and all.
>> >
>> > I have read do_mmap_pgoff and mmap_region more than one hour,
>> > but still can't catch sense about below code in mmap_region:
>> >
>> > "
>> >         /* Clear old maps */
>> >         error = -ENOMEM;
>> > munmap_back:
>> >         if (find_vma_links(mm, addr, addr + len, &prev, &rb_link, &rb_parent)) {
>> >                 if (do_munmap(mm, addr, len))
>> >                         return -ENOMEM;
>> >                 goto munmap_back;
>> >         }
>> > "
>> >
>> > How can we just do_munmap overlapping vma without check its vm_flags
>> > and new vma's vm_flags? I must miss some important things, but I can't
>> > figure out.
>> >
>> > You give below comment about the code in "understand the linux memory manager":)
>> >
>> > "
>> > If a VMA was found and it is part of the new mmapping, this removes the
>> >  old mmapping because the new one will cover both
>> > "
>> >
>> > But if new mmapping has different vm_flags or others' property, how
>> > can we just say the new one will cover both?
>> >
>> > I appreicate any clue and explanation about this headache question.
>> >
>> > Thanks.
>> >
>>
>> Mmap() creates new mapping in given range
>> (new vma might be merged to one or both of sides if possible)
>> so everything what was here before is unmapped in process. Not?
>
> Thanks for reply.
>
> Assme process has vma in region 4096-8192, one page size, mapped to
> a file's first 4096 bytes, then a new map want to create vma in range
> 0-8192 to map 4096-1288 in file, please tell me what's your meaning:
> "so everything what was here before is unmapped in process"?
>
> Why we can just delete old vma for first 4096 size in file which reside
> in range 4096-8192 without notify user process? And create the new vma
> to occupy range 0-8192, do you think "everything" is really the same?

Old and new vmas are intersects? Then that means userpace asked to
create new mapping at fixed address, so it tells kernel to unmap
everything in that range. Without MAP_FIXED kernel always choose free area.

>
> Process lost old map for file's first 4096 bytes, and we use a new
> map for 4096-1288 in file to lie it, and say "the same".
>
> Indeed, I have another question, I guess the answer could save me the
> same as this question.
>
> I have read get_unmapped_area, it seems it will return a unused enough
> region for new vma, and we hold mm->mmap_sem before vm_mmap_pgoff,
> why unused enough region return by get_unmapped_area has overlapping vma
> in mmap_region cause the first question?
>
> I have tested it, running system always call do_munmap in mmap_region, so
> I must miss something important, it is strange.
>
> Thanks again.
>>
>> >
>> >
>> > --
>> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> > the body to majordomo@kvack.org.  For more info on Linux MM,
>> > see: http://www.linux-mm.org/ .
>> > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182])
	by kanga.kvack.org (Postfix) with ESMTP id 092186B0038
	for <linux-mm@kvack.org>; Sat, 21 Mar 2015 04:11:18 -0400 (EDT)
Received: by pdbop1 with SMTP id op1so131077794pdb.2
        for <linux-mm@kvack.org>; Sat, 21 Mar 2015 01:11:17 -0700 (PDT)
Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com. [2607:f8b0:400e:c02::232])
        by mx.google.com with ESMTPS id i5si13269229pde.37.2015.03.21.01.11.16
        for <linux-mm@kvack.org>
        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Sat, 21 Mar 2015 01:11:17 -0700 (PDT)
Received: by pdbcz9 with SMTP id cz9so130991440pdb.3
        for <linux-mm@kvack.org>; Sat, 21 Mar 2015 01:11:16 -0700 (PDT)
Date: Fri, 20 Mar 2015 23:41:25 +0800
From: Wang YanQing <udknight@gmail.com>
Subject: Re: [RFC] Strange do_munmap in mmap_region
Message-ID: <20150320154125.GA3168@udknight>
References: <20150228064647.GA9550@udknight.ahead-top.com>
 <CALYGNiMLwhqQSmj58mT4MWk2RAuU-3TykoSd=XjuXVfqkL3NoA@mail.gmail.com>
 <20150319151214.GA2175@udknight>
 <CALYGNiPjEFLC2uiTGZMqP4TwDBit6+3VaiEpvGELYg8jDsVXBw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALYGNiPjEFLC2uiTGZMqP4TwDBit6+3VaiEpvGELYg8jDsVXBw@mail.gmail.com>
Sender: owner-linux-mm@kvack.org
List-ID: <linux-mm.kvack.org>
To: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Mel Gorman <mgorman@suse.de>, "linux-mm@kvack.org" <linux-mm@kvack.org>, yinghai@kernel.org, Andrew Morton <akpm@linux-foundation.org>

On Thu, Mar 19, 2015 at 06:36:54PM +0300, Konstantin Khlebnikov wrote:
> > Assme process has vma in region 4096-8192, one page size, mapped to
> > a file's first 4096 bytes, then a new map want to create vma in range
> > 0-8192 to map 4096-1288 in file, please tell me what's your meaning:
> > "so everything what was here before is unmapped in process"?
> >
> > Why we can just delete old vma for first 4096 size in file which reside
> > in range 4096-8192 without notify user process? And create the new vma
> > to occupy range 0-8192, do you think "everything" is really the same?
> 
> Old and new vmas are intersects? Then that means userpace asked to
> create new mapping at fixed address, so it tells kernel to unmap
> everything in that range. Without MAP_FIXED kernel always choose free area.
> 

Thanks, Konstantin Khlebnikov, you cure my headache :)

I haven't notice MAP_FIXED.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>