Re: [PATCH v3 01/26] set_memory: add folio_{zap,restore}_direct_map helpers

["Brendan Jackman" <brendan.jackman@linux.dev>]

On Mon Jul 27, 2026 at 10:33 AM UTC, Mike Rapoport wrote:
...
>> +#ifdef CONFIG_ARCH_HAS_SET_DIRECT_MAP
>> +/**
>> + * folio_zap_direct_map - remove a folio from the kernel direct map
>> + * @folio: folio to remove from the direct map
>> + *
>> + * Removes the folio from the kernel direct map and flushes the TLB.  This may
>> + * require splitting huge pages in the direct map, which can fail due to memory
>> + * allocation.  So far, only order-0 folios are supported; this guarantees
>> + * the unmap is either a complete success or a total failure.
>> + *
>> + * Return: 0 on success, or a negative error code on failure.
>> + */
>> +int folio_zap_direct_map(struct folio *folio)
>> +{
>> +	struct page *page = folio_page(folio, 0);
>> +	unsigned long addr = (unsigned long)page_address(page);
>> +	int ret;
>> +
>> +	if (folio_test_large(folio) || folio_test_highmem(folio))
>> +		return -EINVAL;
>> +
>> +	ret = set_direct_map_valid_noflush(page, 1, false);
>
> There was a discussion about  slight differences in the semantics of
> set_direct_map_valid() on x86 and on arm64 and that execmem should
> apparently switch to set_direct_map_{invalid,default}.
>
> Maybe for this series it would be better to add a patch that adds numpages
> to set_direct_map_{invalid,default}_noflush and use
> set_direct_map_default_noflush() here?

Um, I think probably we need to clean that API up a bit overall, and I
think that's probably best handled as a separate patchset?

I think with the API as it currently is, the current usage is correct in
this patchset, and I'm a bit reluctant to grow this patchset any
further (and I didn't want to block v3 on yet another preparatory
series, but potentially blocking v4 on one might make sense).

> And maybe also pick another Nikita's patch [2] that makes set_direct_map_*
> to take address?

I deliberately omitted that, I don't think it's a good idea:

https://lore.kernel.org/all/DJJ2QJQQ73CM.2WHKW4AT6QT1D@linux.dev/

(If we do want to change the API we could use PFNs as I mentioned in
the last message of that thread, but I don't see any need to change that
API).