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: <76zi626uk53dtfzmezzt6cfz45ansam2gpcumddqxnipnw5jkh@qwfzoxgi255b>
Date: Tue, 17 Jun 2025 09:34:16 +0100
From: Pedro Falcato <pfalcato@...e.de>
To: David Hildenbrand <david@...hat.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.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

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


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.

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.

-- 
Pedro