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: <f86c4211-fa9c-43a4-b60a-4fc563fd4d61@redhat.com>
Date: Tue, 17 Jun 2025 13:58:59 +0200
From: David Hildenbrand <david@...hat.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.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 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.

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

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?

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

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.

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

-- 
Cheers,

David / dhildenb