Re: [PATCH] mm/page_alloc: let the bulk and folio allocators carry alloc_flags

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

On Mon Sep 14, 2026 at 5:54 PM BST, Gregory Price wrote:
> On Mon, Sep 14, 2026 at 11:51:14AM -0400, Gregory Price wrote:
>> __alloc_pages_noprof() takes an explicit alloc_flags, but the bulk and
>> folio entry points do not, so callers cannot select allocator behaviour
>> (e.g. an alternate zonelist) through them.
>> 
>> Thread alloc_flags through both, matching __alloc_pages_noprof(), and
>> keep the flag-carrying primitives mm-internal (page_alloc.h) so the
>> public gfp.h wrappers stay flag-free:
>> 
>>  - add __alloc_pages_bulk_noprof(gfp, ..., alloc_flags) in page_alloc.h
>>    alloc_pages_bulk_noprof() becomes a wrapper passing ALLOC_DEFAULT
>> 
>>  - give __folio_alloc_noprof() an alloc_flags parameter and moves
>>    __folio_alloc_node_noprof() moves into page_alloc.h
>>    __folio_alloc_noprof() is no longer exported
>> 
>> No functional change: every caller passes ALLOC_DEFAULT.
>> 
>> Cc: Brendan Jackman <brendan.jackman@linux.dev>
>> Signed-off-by: Gregory Price <gourry@gourry.net>
>> ---
>> 
>> Brendan this will conflict mildly with your ALLOC_UNMAPPED work,
>> because you add an init_alloc_flags call in alloc_pages_bulk_noprof :
>> https://lore.kernel.org/linux-mm/20260726-page_alloc-unmapped-v3-20-6f5729aa9832@google.com/
>> 
>> I wanted to pull this out ahead to try to deal with the conflict.
>> 
>
> Sashiko pointed out some issues that arise from rebasing on the recent
> ALLOC_NOLOCK work, and in a quick review I found a similar slow-path
> fallback issue with the NOBLOCK patch separate of this patch.
>
> Brendan, if you're alright with it, can I pull the NOBLOCK patch out
> ahead into a 2-commit series and I'll add the small fixups?

Hey, sorry about the silence I let LKML pile up rather badly, it's been
quite a month..

Yes I am totally alright with this (glad to see you went ahead).