Re: [PATCH v4 01/12] mm: introduce AS_NO_DIRECT_MAP

[Vlastimil Babka]

On 2/25/25 17:52, David Hildenbrand wrote:
> On 21.02.25 17:07, Patrick Roy 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.
>> 
>> 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 gfp_t mapping_gfp_mask(struct address_space * mapping)
>>   {
>>   	return mapping->gfp_mask;
>> diff --git a/lib/buildid.c b/lib/buildid.c
>> index c4b0f376fb34..80b5d805067f 100644
>> --- a/lib/buildid.c
>> +++ b/lib/buildid.c
>> @@ -65,8 +65,8 @@ static int freader_get_folio(struct freader *r, loff_t file_off)
>>   
>>   	freader_put_folio(r);
>>   
>> -	/* reject secretmem folios created with memfd_secret() */
>> -	if (secretmem_mapping(r->file->f_mapping))
>> +	/* reject secretmem folios created with memfd_secret() or guest_memfd() */
>> +	if (secretmem_mapping(r->file->f_mapping) || mapping_no_direct_map(r->file->f_mapping))
>>   		return -EFAULT;
> 
> Maybe I'm missing it, but why do we have to special-case secretmem with 
> that at all anymore?
> 
> Couldn't we just let secretmem set AS_NO_DIRECT_MAP as well, and convert 
> all/most secretmem specific stuff to check AS_NO_DIRECT_MAP as well?

That's done in patch 02. But yeah, squashing them together would reduce some
churn. I guess because it removes some !IS_ENABLED(CONFIG_SECRETMEM)
optimizations, a separate change for review was preferred.