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

[Gregory Price]

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@xxxxxxxxx>
> Signed-off-by: Gregory Price <gourry@xxxxxxxxxx>
> ---
> 
> 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@xxxxxxxxxx/
> 
> 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?

~Gregory