linux-kernel - Re: [RFC PATCH 1/8] mm/madvise: propagate vma->vm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <6496185C-6792-4D67-AF5D-E049A8DC65B8@gmail.com>
Date:   Mon, 27 Sep 2021 05:59:50 -0700
From:   Nadav Amit <nadav.amit@...il.com>
To:     "Kirill A. Shutemov" <kirill@...temov.name>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Linux-MM <linux-mm@...ck.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Peter Xu <peterx@...hat.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Minchan Kim <minchan@...nel.org>,
        Colin Cross <ccross@...gle.com>,
        Suren Baghdasarya <surenb@...gle.com>,
        Mike Rapoport <rppt@...ux.vnet.ibm.com>
Subject: Re: [RFC PATCH 1/8] mm/madvise: propagate vma->vm_end changes



> On Sep 27, 2021, at 5:45 AM, Kirill A. Shutemov <kirill@...temov.name> wrote:
> 
> On Mon, Sep 27, 2021 at 05:33:39AM -0700, Nadav Amit wrote:
>> 
>> 
>>> On Sep 27, 2021, at 4:55 AM, Kirill A. Shutemov <kirill@...temov.name> wrote:
>>> 
>>> On Mon, Sep 27, 2021 at 03:11:20AM -0700, Nadav Amit wrote:
>>>> 
>>>>> On Sep 27, 2021, at 2:08 AM, Kirill A. Shutemov <kirill@...temov.name> wrote:
>>>>> 
>>>>> On Sun, Sep 26, 2021 at 09:12:52AM -0700, Nadav Amit wrote:
>>>>>> From: Nadav Amit <namit@...are.com>
>>>>>> 
>>>>>> 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).
>>>>>> 
>> 

[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.
> 
> It should work.
> 
> 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).