linux-kernel - Re: [RFC PATCH 1/7] 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: <335b3432-af06-420f-b575-7a1d92148f6b@redhat.com>
Date: Sun, 23 Mar 2025 13:49:07 +0100
From: David Hildenbrand <david@...hat.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Jann Horn <jannh@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>,
 Vlastimil Babka <vbabka@...e.cz>, "Liam R . Howlett"
 <Liam.Howlett@...cle.com>, Suren Baghdasaryan <surenb@...gle.com>,
 Matthew Wilcox <willy@...radead.org>, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/7] mm/mremap: introduce more mergeable mremap via
 MREMAP_RELOCATE_ANON

>>
>> c)  In -next, there is now be the option to use folio lock +
>> folio_maybe_mapped_shared() == false. But it doesn't tell you into how many
>> VMAs a large folio is mapped into.
>>
>> In the following case:
>>
>> [       folio     ]
>> [ VMA#1 ] [ VMA#2 ]
>>
>> c) would not tell you if you are fine modifying the folio when moving VMA#2.
> 
> Right, I feel like prior checks made should assert this is not the case,
> however?  But mapcount check should be a last ditch assurance?

Something nice might be hiding in c) that might be able to handle a 
single folio being covered by multiple vmas.

I was thinking about the following:

[       folio0     ]
[       VMA#0      ]

Then we do a partial (old-school) mremap()

[ folio0 ]               [ folio0 ]
[ VMA#1  ]               [ VMA#2  ]

To then extend VMA#1 and fault in pages

[ folio0 ][ folio1 ]         [ folio0 ]
[      VMA#1       ]         [ VMA#2  ]

If that is possible (did not try!, maybe something prevents us from 
extending VMA#1) mremap(MREMAP_RELOCATE_ANON) of VMA#1  / VMA#2 cannot work.

We'd have to detect that scenario (partial mremap). You might be doing 
that with the anon-vma magic, something different might be: Assume we 
flag large folios if they were partially mremapped in any process.

Then (with folio lock only)

1) folio_maybe_mapped_shared() == false: mapped into single process
2) folio_maybe_partially_mremaped() == false: not scattered in virtual
    address space

It would be sufficient to check if the folio fully falls into the 
memap() range to decide if we can adjust the folio index etc.

We *might* be able to use that in the COW-reuse path for large folios to 
perform a folio_move_anon_rmap(), which we currently only perform for 
small folios / PMD-mapped folios (single mapping). Not sure yet if 
actually multiple VMAs are involved.

Just throwing it out there ...
> 
> (actually at least one of the 'prior checks' for large folios are added in a
> later commit but still :P)

Yeah, I'm looking at the bigger picture; small folios are easy :P

-- 
Cheers,

David / dhildenb