Re: [RFC PATCH 1/2] mm/secretmem: try to restore large page mappings in direct map

["David Hildenbrand (Arm)" <david@kernel.org>]

On 6/3/26 15:09, Lance Yang wrote:
> 
> 
> On 2026/6/3 20:35, Mike Rapoport wrote:
>> On Wed, Jun 03, 2026 at 07:41:34PM +0800, Lance Yang wrote:
>>>
>>> Good point, I kept it separate on purpose :)
>>>
>>> Putting collapse into set_direct_map_default_noflush() would change the
>>> semantics of that helper a bit, IMHO.
>>
>> For x86 default means present + rw + PSE, so yuu can look at it as actually
>> better enforcing the semantics :)
> 
> Yep. One x86 detail though, default seems to miss _PAGE_GLOBAL today. Not
> sure if that is intentional or just historical. See patch #02.
> 
>>> I would expect arch_try_collapse_direct_map() to also be useful for cases
>>> where a direct-map permission change could split a large maping first,
>>> and the user wants to try restoring the large mapping after changing it
>>> back. One example[1] is making a direct-map range read-only for security,
>>> which I am also working on :)
>>
>> I don't think users should care. The users care for particular permissions
>> of a range in the direct map. It should be up to the architecture to select
>> most suitable mapping size. The splits are implicit, I don't see why
>> collapses can't be implicit as well.
> 
> And agreed, users should not care about the final mapping size, that is
> up to the arch.
> 
> TBH, my concern is making the collapse cost implicit for every
> set_direct_map_default_noflush() caller. I still lean toward keeping
> it opt-in, but happy to hear what folks prefer :)

If we could easily do that automatically, that would likely be preferable.

Especially given that we are getting other users of direct-map removal soon that
would face similar problems (e.g., guest_memfd).

What the performance impact of trying to collapse after every directmap update?
Imagine we have a full PMD range with directmap-removed PTEs?

-- 
Cheers,

David