Re: [PATCH v5 03/12] mm: introduce AS_NO_DIRECT_MAP

[Roy, Patrick]

On Thu, 2025-08-28 at 22:00 +0100, David Hildenbrand wrote:
> On 28.08.25 11:39, Roy, Patrick wrote:
>> Add AS_NO_DIRECT_MAP for mappings where direct map entries of folios are
>> set to not present . Currently, mappings that match this description are
>> secretmem mappings (memfd_secret()). Later, some guest_memfd
>> configurations will also fall into this category.
>>
>> Reject this new type of mappings in all locations that currently reject
>> secretmem mappings, on the assumption that if secretmem mappings are
>> rejected somewhere, it is precisely because of an inability to deal with
>> folios without direct map entries, and then make memfd_secret() use
>> AS_NO_DIRECT_MAP on its address_space to drop its special
>> vma_is_secretmem()/secretmem_mapping() checks.
>>
>> This drops a optimization in gup_fast_folio_allowed() where
>> secretmem_mapping() was only called if CONFIG_SECRETMEM=y. secretmem is
>> enabled by default since commit b758fe6df50d ("mm/secretmem: make it on
>> by default"), so the secretmem check did not actually end up elided in
>> most cases anymore anyway.
>>
>> Use a new flag instead of overloading AS_INACCESSIBLE (which is already
>> set by guest_memfd) because not all guest_memfd mappings will end up
>> being direct map removed (e.g. in pKVM setups, parts of guest_memfd that
>> can be mapped to userspace should also be GUP-able, and generally not
>> have restrictions on who can access it).
>>
>> Signed-off-by: Patrick Roy <roypat@xxxxxxxxxxxx>
>> ---
> [...]
> 
>> +static inline bool vma_is_no_direct_map(const struct vm_area_struct *vma)
>> +{
>> +     return vma->vm_file && mapping_no_direct_map(vma->vm_file->f_mapping);
>> +}
>> +
> 
> "vma_is_no_direct_map" reads a bit weird.
> 
> "vma_has_no_direct_map" or "vma_no_direct_mapping" might be better.

I went with "vma_has_no_direct_map" for now, because vma_no_direct_mapping
would imply (to me at least) changing "mapping_no_direct_map" to
"mapping_no_direct_mapping", which also reads a bit weird imo.

> With the comment Mike and Fuad raised, this LGTM.
> 
> 
> -- 
> Cheers
> 
> David / dhildenb

Best,
Patrick