Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: Re: [RFC PATCH 1/8] mm/madvise: propagate vma->vm_end changes
From:   Nadav Amit <nadav.amit@gmail.com>
In-Reply-To: <20210927124518.gjas4itro5c3park@box.shutemov.name>
Date:   Mon, 27 Sep 2021 05:59:50 -0700
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Linux-MM <linux-mm@kvack.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Peter Xu <peterx@redhat.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Minchan Kim <minchan@kernel.org>,
        Colin Cross <ccross@google.com>,
        Suren Baghdasarya <surenb@google.com>,
        Mike Rapoport <rppt@linux.vnet.ibm.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6496185C-6792-4D67-AF5D-E049A8DC65B8@gmail.com>
References: <20210926161259.238054-1-namit@vmware.com>
 <20210926161259.238054-2-namit@vmware.com>
 <20210927090852.sc5u65ufwvfx57rl@box.shutemov.name>
 <A923D77C-8C45-41B0-A1B2-55F68168D058@gmail.com>
 <20210927115507.6xfpugeg3swookbh@box>
 <4211F6D4-A282-4AB4-8D96-E273C5ABE0DF@gmail.com>
 <20210927124518.gjas4itro5c3park@box.shutemov.name>
To:     "Kirill A. Shutemov" <kirill@shutemov.name>
Precedence: bulk


> On Sep 27, 2021, at 5:45 AM, Kirill A. Shutemov <kirill@shutemov.name> =
wrote:
>=20
> On Mon, Sep 27, 2021 at 05:33:39AM -0700, Nadav Amit wrote:
>>=20
>>=20
>>> On Sep 27, 2021, at 4:55 AM, Kirill A. Shutemov =
<kirill@shutemov.name> wrote:
>>>=20
>>> On Mon, Sep 27, 2021 at 03:11:20AM -0700, Nadav Amit wrote:
>>>>=20
>>>>> On Sep 27, 2021, at 2:08 AM, Kirill A. Shutemov =
<kirill@shutemov.name> wrote:
>>>>>=20
>>>>> On Sun, Sep 26, 2021 at 09:12:52AM -0700, Nadav Amit wrote:
>>>>>> From: Nadav Amit <namit@vmware.com>
>>>>>>=20
>>>>>> The comment in madvise_dontneed_free() says that vma splits that =
occur
>>>>>> while the mmap-lock is dropped, during userfaultfd_remove(), =
should be
>>>>>> handled correctly, but nothing in the code indicates that it is =
so: prev
>>>>>> is invalidated, and do_madvise() will therefore continue to =
update VMAs
>>>>>> from the "obsolete" end (i.e., the one before the split).
>>>>>>=20
>>=20

[snip]


>> Perhaps adding this one on top of yours? I can test it when I wake =
up.
>> It is cleaner, but I am not sure if I am missing something.
>=20
> It should work.
>=20
> BTW, shouldn't we bring madvise_willneed() and madvise_remove() to the
> same scheme?

Even for consistency you are right. My only problem is that I am afraid
to backport such a change. For MADV_DONTNEED, I saw an explicit =
assumption.
I can do it all in one patch if we agree that none of it goes into =
stable
(which I clumsily forgot to cc, but might find the patch and backport =
it).=