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

[Vlastimil Babka (SUSE)]

On 9/23/26 03:59, Gregory Price wrote:
> 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.

It's possible to document it as unsupported, add a VM_WARN_ON_ONCE etc.
It's not necessary for bulk alloc to support ALLOC_NOLOCK just because it
takes flags. e.g. kmalloc_nolock() supports a subset of gfp flags as well.

> 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