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

[Gregory Price <gourry@gourry.net>]

On Tue, Sep 22, 2026 at 09:05:58PM +0800, Lance Yang 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.
> 
> 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

There is some concern around NOLOCK here yes, in fact sashiko picked
this issue up and I've been poking at it.

I've actually been reworking this patch and pulled in changes from the
ALLOC_UNMAPPED series to address this all at once.  I've been developing
a page allocator unit-testing harness to help validate some assumptions
before I post it.

~Gregory