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: <93528cdf-93d1-4931-b668-51c9fb29d73c@lucifer.local>
Date: Tue, 17 Jun 2025 13:47:39 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: David Hildenbrand <david@...hat.com>
Cc: Pedro Falcato <pfalcato@...e.de>,
        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 Tue, Jun 17, 2025 at 01:58:59PM +0200, David Hildenbrand wrote:
> On 17.06.25 12:57, Lorenzo Stoakes wrote:
> > On Tue, Jun 17, 2025 at 10:45:53AM +0200, David Hildenbrand wrote:
> > > mremap() is already an expensive operation ... so I think we need a pretty
> > > convincing case to make this configurable by the user at all for each
> > > individual mremap() invocation.
> >
> > My measurements suggest, unless you hit a very unfortunate case of -huge
> > faulted in range all mapped PTE- that the work involved is not all that
> > much more substantial in terms of order of magnitude than a normal mremap()
> > operation.
>
> Which means we could at least try without such a flag.
>
> Regarding MREMAP_MUST_RELOCATE_ANON, I absolutely hate it.

Ack this isn't life or death we can drop it.

>
> I'll reply to your comment to my other mail once I get to it.

Thanks!

I know this is a gnarly series so appreciate you (and Harry of course!) looking.

>
> Users that really care (testing) could figure out if merging worked by
> looking at /proc/. Other users ... no idea what they are even supposed to do
> in that case. Not mremap()? But what is the use case ...
>
> If the "not merged" case would be relevant, a workaround would be ...
> mremapping it simply back?

True true.

>
> So if we can, let's just try without any of these flags first.

Ack.

>
> MREMAP_MUST_RELOCATE_ANON could always be added later on top, once the use
> case for it is clear. Removing it from this series would not make this
> series any less valuable I think.

Sure.

>
> (and of course, doing it without any flags will make this series much more
> valuable :P )

Yeah, I'd prefer this overall if possible...

>
> --
> Cheers,
>
> David / dhildenb
>
>

Thinking of undo, here's an idea:

1. increment refcount on folio
2. isolate from LRU
3. Add to linked list

Do this for all folios.

Then if we encounter a problem we can simply walk the list + fixup, drop
refcount, re-add to LRU.

It's ugly, but it guarantees we can undo what we set?