Re: [PATCH v3 19/26] mm/page_alloc: rename ALLOC_NON_BLOCK back to _HARDER

On Tue Aug 18, 2026 at 2:45 AM CEST, Yosry Ahmed wrote:
> On Fri, Aug 14, 2026 at 01:09:32PM +0100, Brendan Jackman wrote:
>> On Tue Aug 4, 2026 at 10:50 PM BST, Yosry Ahmed wrote:
>> > On Fri, Jul 31, 2026 at 04:52:59PM +0200, Vlastimil Babka (SUSE) wrote:
>> >> On 7/27/26 00:22, Brendan Jackman wrote:
>> >> > Commit 1ebbb21811b7 ("mm/page_alloc: explicitly define how __GFP_HIGH
>> >> > non-blocking allocations accesses reserves") renamed ALLOC_HARDER to
>> >> > ALLOC_NON_BLOCK because the former is "a vague description".
>> >> > 
>> >> > However, vagueness is accurate here, this is a vague flag. It is not set
>> >> > for __GFP_NOMEMALLOC. It doesn't really mean "allocate without blocking"
>> >> > but rather "allow dipping into atomic reserves, _because_ of the need
>> >> > not to block".
>> >> > 
>> >> > A later commit will need an alloc flag that really means "don't block
>> >> > here", so go back to the flag's old name and update the commentary
>> >> > to try and give it a slightly clearer meaning.
>> >> > 
>> >> > Signed-off-by: Brendan Jackman <[email protected]>
>> 
>> Writing this to get it clear in my head, so I'll also dump it in the
>> mail in case it helps get us on the same page... 
>> 
>> What we actually want here is a flag that tells us when we can do a TLB
>> shootdown. That means (on x86) that IRQs must be on and we mustn't be
>> holding some random spinlock (most spinlocks would actually be fine but
>> I think it's simpler to assume we can't hold any). 
>> 
>> It must never be over-permissive i.e. tell us we can do a TLB flush
>> when we can't. It's fine to _sometimes_ be over-restrictive i.e. tell us
>> we can't do a TLB flush when we can, but if it always forbids flushing
>> while GFP_BOOT_MASK is in effect then we'll fail critical allocations
>> and crash.
>
> Why is it a problem if it forbids flushing while GFP_BOOT_MASK is in
> effect? We should change gfp_allowed_mask before any unmapped
> allocations are possible, right?

Hm, good point... I don't remember why this was a problem. It certainly
seems like it shoudl be OK for secretmem and guest_memfd.