Re: [PATCH] mm/secretmem: disable under HIGHMEM

[Brendan Jackman]

On Thu Jul 16, 2026 at 10:52 AM UTC, Mike Rapoport wrote:
> On Thu, Jul 16, 2026 at 12:08:07PM +0200, David Hildenbrand (Arm) wrote:
>> On 7/15/26 16:58, Mike Rapoport wrote:
>> > On Wed, Jul 15, 2026 at 03:49:39PM +0200, David Hildenbrand (Arm) wrote:
>> >> On 7/15/26 15:44, Mike Rapoport wrote:
>> >>>
>> >>> No, I mean what Brendan's patch did:
>> >>>
>> >>>  config SECRETMEM
>> >>>         default y
>> >>>         bool "Enable memfd_secret() system call" if EXPERT
>> >>> -       depends on ARCH_HAS_SET_DIRECT_MAP
>> >>> +       depends on ARCH_HAS_SET_DIRECT_MAP && !HIGHMEM
>> >>>
>> >>> We can change gfp_mask as well for the sake of pedancy
>> >>
>> >> Why not change the gfp mask only then?
>> > 
>> > Citing myself from a few emails back: 
>> > 
>> >>> But still with kmap() and friends not being an NOP the promise "kernel does
>> >>> not map this memory" does not hold.
>> 
>> So you're saying that kmap() would perform a mapping for a non-highmem page?
>> 
>> static inline void *kmap(struct page *page)
>> {
>> 	void *addr;
>> 
>> 	might_sleep();
>> 	if (!PageHighMem(page))
>> 		addr = page_address(page);
>> 	else
>> 		addr = kmap_high(page);
>> 	kmap_flush_tlb((unsigned long)addr);
>> 	return addr;
>> }
>> 
>> I'm missing something important.
>
> Yeah, you are right, GFP_USER should do.

Cool thanks folks, looks like we have a consensus.

I lost my cached so I need to compile a 32bit OS again to test with
GFP_USER, and I am on holiday next week so it might be a while before v2
(depends what kind of holiday it turns out to be!).

I assume nobody is in a rush here but just in case someone doesn't want
to wait for the fix, just let me know if you wanna take over from here.