linux-kernel - Re: RFC for new feature to move pages from one vma to another without split

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] [day] [month] [year] [list]

Message-ID: <CAJuCfpHEXDiUBGZ1RCiHRyewTQ_6NNG3+PvLQuhn99eCmPbgTA@mail.gmail.com>
Date:   Thu, 14 Sep 2023 08:30:59 -0700
From:   Suren Baghdasaryan <surenb@...gle.com>
To:     Lokesh Gidra <lokeshgidra@...gle.com>
Cc:     Vlastimil Babka <vbabka@...e.cz>, Peter Xu <peterx@...hat.com>,
        David Hildenbrand <david@...hat.com>,
        Axel Rasmussen <axelrasmussen@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "open list:MEMORY MANAGEMENT" <linux-mm@...ck.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Andrea Arcangeli <aarcange@...hat.com>,
        "Kirill A . Shutemov" <kirill@...temov.name>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Brian Geffon <bgeffon@...gle.com>,
        Kalesh Singh <kaleshsingh@...gle.com>,
        Nicolas Geoffray <ngeoffray@...gle.com>,
        Jared Duke <jdduke@...gle.com>,
        android-mm <android-mm@...gle.com>,
        Blake Caldwell <blake.caldwell@...orado.edu>,
        Mike Rapoport <rppt@...nel.org>
Subject: Re: RFC for new feature to move pages from one vma to another without split

On Thu, Jun 8, 2023 at 3:05 AM Lokesh Gidra <lokeshgidra@...gle.com> wrote:
>
> On Tue, Jun 6, 2023 at 4:18 PM Suren Baghdasaryan <surenb@...gle.com> wrote:
> >
> > On Tue, Jun 6, 2023 at 1:15 PM Vlastimil Babka <vbabka@...e.cz> wrote:
> > >
> > > On 4/13/23 17:36, Peter Xu wrote:
> > > > On Thu, Apr 13, 2023 at 10:10:44AM +0200, David Hildenbrand wrote:
> > > >> So instead, we consider the whole address space as a virtual, anon file,
> > > >> starting at offset 0. The pgoff of a VMA is then simply the offset in that
> > > >> virtual file (easily computed from the start of the VMA), and VMA merging is
> > > >> just the same as for an ordinary file.
> > > >
> > > > Interesting point, thanks!
> > >
> > > FYI, I've advised a master thesis exploring how to update page->index during
> > > mremap() to keep things mergeable:
> > >
> > > https://dspace.cuni.cz/bitstream/handle/20.500.11956/176288/120426800.pdf
> > >
> > > I think the last RFC posting was:
> > > https://lore.kernel.org/all/20220516125405.1675-1-matenajakub@gmail.com/
> > >
> > > It was really tricky for the general case. Maybe it would be more feasible
> > > for the limited case Lokesh describes, if we could be sure the pages that
> > > are moved aren't mapped anywhere else.
>
> It's great that mremap is being improved for mereabilitly. However,
> IIUC, it would still cause unnecessary splits and merges in the
> private anonymous case. Also, mremap works with mmap_sem exclusively
> held, thereby impacting scalability of concurrent mremap calls.
>
> IMHO, Andrea's userfaultfd REMAP patch is a better alternative as it
> doesn't have these downsides.
>
> >
> > Lokesh asked me to pick up this work and prepare patches for
> > upstreaming. I'll start working on them after I finish with per-vma
> > lock support for swap and userfaultd (targeting later this week).
> > Thanks for all the input folks!
>
> Thanks so much, Suren!

I just posted the patchset at
https://lore.kernel.org/all/20230914152620.2743033-1-surenb@google.com/.
I tried to keep it as true to Andrea's original as possible but still
had to make some sizable changes, which I described in the cover
letter. Feedback would be much appreciated!