linux-kernel - Re: [PATCH 00/11] mm/mremap: introduce more mergeable mremap via MREMAP_RELOCATE

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: <2897750a-3aba-4488-b3e6-4fce23aaa23b@lucifer.local>
Date: Tue, 17 Jun 2025 11:20:15 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Pedro Falcato <pfalcato@...e.de>
Cc: David Hildenbrand <david@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Vlastimil Babka <vbabka@...e.cz>, Jann Horn <jannh@...gle.com>,
        "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Suren Baghdasaryan <surenb@...gle.com>,
        Matthew Wilcox <willy@...radead.org>, Rik van Riel <riel@...riel.com>,
        Harry Yoo <harry.yoo@...cle.com>, Zi Yan <ziy@...dia.com>,
        Baolin Wang <baolin.wang@...ux.alibaba.com>,
        Nico Pache <npache@...hat.com>, Ryan Roberts <ryan.roberts@....com>,
        Dev Jain <dev.jain@....com>, Jakub Matena <matenajakub@...il.com>,
        Wei Yang <richard.weiyang@...il.com>, Barry Song <baohua@...nel.org>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/11] mm/mremap: introduce more mergeable mremap via
 MREMAP_RELOCATE_ANON

Replying to parent but quickly reply here also... out of order, like pulp
fiction...

On Tue, Jun 17, 2025 at 09:34:16AM +0100, Pedro Falcato wrote:
> On Mon, Jun 16, 2025 at 10:41:20PM +0200, David Hildenbrand wrote:
> > On 16.06.25 22:24, David Hildenbrand wrote:
> > > Hi Lorenzo,
> > >
> > > as discussed offline, there is a lot going on an this is rather ... a
> > > lot of code+complexity for something that is more a corner cases. :)
> > >
> > > Corner-case as in: only select user space will benefit from this, which
> > > is really a shame.
> > >
> > > After your presentation at LSF/MM, I thought about this further, and I
> > > was wondering whether:
> > >
> > > (a) We cannot make this semi-automatic, avoiding flags.
> > >
> > > (b) We cannot simplify further by limiting it to the common+easy cases
> > > first.
> > >
> > > I think you already to some degree did b) as part of this non-RFC, which
> > > is great.
> > >
> > >
> > > So before digging into the details, let's discuss the high level problem
> > > briefly.
> > >
> > > I think there are three parts to it:
> > >
> > > (1) Detecting whether it is safe to adjust the folio->index (small
> > >       folios)
> > >
> > > (2) Performance implications of doing so
> > >
> > > (3) Detecting whether it is safe to adjust the folio->index (large PTE-
> > >       mapped  folios)
> > >
> > >
> > > Regarding (1), if we simply track whether a folio was ever used for
> > > COW-sharing, it would be very easy: and not only for present folios, but
> > > for any anon folios that are referenced by swap/migration entries.
> > > Skimming over patch #1, I think you apply a similar logic, which is good.
> > >
> > > Regarding (2), it would apply when we mremap() anon VMAs and they happen
> > > to reside next to other anon VMAs. Which workloads are we concerned
> > > about harming by implementing this optimization? I recall that the most
> > > common use case for mremap() is actually for file mappings, but I might
>
> realloc() for mmapped allocations commonly calls mremap(), FYI (at least for
> glibc, and musl; can't bother to look at the rest).
>
> > > be wrong. In any case, we could just have a different way to enable this
> > > optimization than for each and every mremap() invocation in a process.
>
> /me thinks of prctl
>
> :P

God please :P

>
>
> FWIW, with regards to the whole feature: While I do understand it's purpose (
> relocating anon might be too much for most workloads, but great for some), I'm
> uncomfortable with the amount of internals we're exposing here. Who's to say
> this is how mm rmap looks in 20 years? And we're stuck maintaining the userspace
> ABI until then.

I'm not sure what internals exactly we're exposing... if we have a future (I am
working on it...) where anon rmap works better then these flags become no-ops
right?

Unless you just mean the name?

I am open to changing the name but I think I already changed it based on what I
thought David might say :P

>
> Personally, I would prefer if we just had a flag 'MREMAP_HARDER' that would
> vaguely be documented as "mremap but harder, even if have to do a little more
> work". Then we could move things around without promising RELOCATE_ANON makes
> conceptual sense, and userspace wouldn't have to think through the implications
> of such a flag by reading Lorenzo's great book.

Well thanks for book plug ;)

I think that's far too vague though. I don't think users would have any idea
what that's supposed to help. And then how does the MREMAP_MUST_RELOCATE_ANON
flag work here?

Naming is hard, basically.

>
> --
> Pedro
>