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

[Vlastimil Babka (SUSE)]

On 7/31/26 16:52, 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 <jackmanb@xxxxxxxxxx>
> 
> I wonder if we need to do this, and instead we could repurpose
> ALLOC_NON_BLOCK directly. AFAIU it's about removing the side-effect of
> gfp_allowed_mask in the next patch. But what would happen if we did that
> using the existing ALLOC_NON_BLOCK (or maybe just renamed to ALLOC_NOBLOCK?).

Hm given how ALLOC_NOLOCK and ALLOC_NOBLOCK look so similar they can be
easily confused (at least by me), I'm not even sure about the rename.