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

[Lance Yang]

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.

Yeah, but what if a caller passes ALLOC_NOLOCK in the future?

__alloc_pages_noprof() checks alloc_nolock_allowed() first, but
__alloc_pages_bulk_noprof() can enter its fast path without that check.

That fast path can reach _deferred_grow_zone() or pcp_spin_trylock().
Shouldn't we do the same check first?

Or am I missing something?

Cheers, Lance