Re: [PATCH RFC 00/19] mm: Add __GFP_UNMAPPED

[Brendan Jackman <jackmanb@google.com>]

Hey Vlastimil, sorry for the delay I've been unexpectedly out of office.

On Mon Mar 2, 2026 at 3:36 PM UTC, Vlastimil Babka (SUSE) wrote:
> On 2/25/26 17:34, Brendan Jackman wrote:
>> .:: What? Why?
>> .:: Why [RFC]?
>> 
>> I really wanted to stop sending RFC and start sending PATCHes but
>> getting this series out has taken months longer than I expected, so it's
>> time to get something on the list. The known issues here are:
>> 
>> 1. __GFP_UNMAPPED isn't useful yet until guest_memfd unmapping support
>>    [0] gets merged.
>> 
>> 2. Apparently while implementing the mm-local region, I totally forgot
>>    that KPTI existed on 32-bit systems. I expect the 0-day bot to fire a
>>    failure on that patch.

> I don't think you mentioned (at least in the cover letter) the mm resistance
> to add new gfp flags due to number of them being uncomfortably close to 32
> already. But I see you've put the new one behind a config. Together with
> point 2 I wonder if this is where we can start making some flags and
> associated functionality 64-bit only and change gfp_t to unsigned long?

Yeah, making __GFP_UNMAPPED 64bit-only would be fine with me.

Ultimately the fact that we have KPTI for 32-bit makes it sound like we
would also want ASI for 32-bit, so I guess I would still want to add a
GFP flag to support that on 32-bit. But that's a pretty futuristic
problem, I would say we should focus on __GFP_UNMAPPED in isolation
right now.

(Just to be clear regarding point 2 - that bug still matters, even if
__GFP_UNMAPPED itself is 64-bit only the mm-local region is separate
and needs to be correct on 32-bit).