[PATCH v2 00/13] mm: Some cleanups for page allocator APIs

[PATCH v2 00/13] mm: Some cleanups for page allocator APIs

[Brendan Jackman]

Some tweaks and cleanups for page allocator entrypoint and flags. This
is motivated by preparation for __GFP_UNMAPPED [1] (which will probably
become ALLOC_UNMAPPED in its next iteration), but all this is supposed
to be an improvement to the codebase in its own right: unifying code
paths, reducing API surface, and removing GFP flags.

[1] https://lore.kernel.org/all/20260320-page_alloc-unmapped-v2-0-28bf1bd54f41@google.com/

This started with unifying  __alloc_frozen_pages[_nolock]_noprof() and
expanded from there.

Unifying the nolock allocator entrypoint with the normal allocator
entrypoint means adding an alloc_flags argument to the later (only
exposed within mm/). This presents an opportunity to take advantage of
that arg to remove some GFP flags, if we add that alloc_flags arg a bit
more broadly to allocator entrypoints.

To distinguish between mm-internal and "public" allocator entrypoints,
it makes sense to use the __ prefix. There are already some public APIs
with that prefix. For *alloc_pages*, just removing those variants seems
like a nice cleanup anyway, so do that. For get_free_pages, the "__"
variant is the _only_ variant and it's very widely used, so it doesn't
seem worthwhile to modify that. Therefore, scope this "__" change
specifically to the *alloc_pages* API, which means we leave the
*folio_alloc* API untouched too, even though that could probably be
cleaned up if so desired.

Tested:

- KVM, mm, and BPF selftests in a QEMU VM

- kunit.py on x86_64

- For the ALLOC_NO_CODETAG bits I just booted a VM and read
  /proc/allocinfo. I confirmed that if I remove ALLOC_NO_CODETAG, the
  kernel crashes in early boot, so I was at least booting code that
  depends on this logic.

I used Google's internal version of Antigravity (AI coding harness) to
do the repetitive bits, those commits are marked with Assisted-by, the
rest is manual.

Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
Changes in v2:
- Fixed up whitespace in nolock unification patch
- Introduced ALLOC_DEFAULT to replace literal 0 for alloc_flags
- All other patches are new
- Link to v1: https://patch.msgid.link/20260617-alloc-trylock-v1-1-83fd7858832e@google.com

---
Brendan Jackman (13):
      mm/page_alloc: rename ALLOC_TRYLOCK -> ALLOC_NOLOCK
      mm/page_alloc: some renames to clarify alloc_flags scopes
      mm/page_alloc: unify __alloc_frozen_pages[_nolock]_noprof()
      mm/page_alloc: relax GFP WARN in nolock allocs
      perf/x86/intel: Use higher-level allocator
      KVM: VMX: Use higher-level allocator
      x86/virt: Use higher-level allocator
      sgi-xp: Use higher-level allocator
      net/funeth: Switch to higher-level allocator
      mm: Remove __alloc_pages_node()
      alloc_tag: Move to mm/
      mm: Move __alloc_pages() to mm/internal.h
      mm: remove __GFP_NO_CODETAG

 Documentation/admin-guide/cgroup-v1/cpusets.rst  |   2 +-
 Documentation/admin-guide/mm/transhuge.rst       |   2 +-
 MAINTAINERS                                      |   2 +-
 arch/x86/events/intel/ds.c                       |   6 +-
 arch/x86/kvm/vmx/vmx.c                           |   2 +-
 arch/x86/virt/hw.c                               |   2 +-
 drivers/misc/sgi-xp/xpc_uv.c                     |   2 +-
 drivers/net/ethernet/fungible/funeth/funeth_rx.c |   2 +-
 include/linux/gfp.h                              |  28 +--
 lib/Makefile                                     |   1 -
 mm/Makefile                                      |   1 +
 {lib => mm}/alloc_tag.c                          |  18 +-
 mm/compaction.c                                  |   4 +-
 mm/hugetlb.c                                     |   3 +-
 mm/internal.h                                    |  20 +-
 mm/mempolicy.c                                   |  10 +-
 mm/page_alloc.c                                  | 254 +++++++++++++----------
 mm/page_frag_cache.c                             |   4 +-
 mm/slub.c                                        |   6 +-
 19 files changed, 193 insertions(+), 176 deletions(-)
---
base-commit: cbe5256a15fc26f592efb037e528da54b2139ee5
change-id: 20260617-alloc-trylock-14ad37dab337

Best regards,
--  
Brendan Jackman <jackmanb@google.com>

[PATCH v2 06/13] KVM: VMX: Use higher-level allocator

[Brendan Jackman]

The difference between __alloc_pages_node() and alloc_pages_node() is
that the former allows you to pass NUMA_NO_NODE.

The former is going away and the latter works fine here so switch over.

Cc: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org
Assisted-by: Gemini:unknown-version
Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
 arch/x86/kvm/vmx/vmx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index b9103de01428e..23ba400b30eec 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -2994,7 +2994,7 @@ struct vmcs *alloc_vmcs_cpu(bool shadow, int cpu, gfp_t flags)
 	struct page *pages;
 	struct vmcs *vmcs;
 
-	pages = __alloc_pages_node(node, flags, 0);
+	pages = alloc_pages_node(node, flags, 0);
 	if (!pages)
 		return NULL;
 	vmcs = page_address(pages);

-- 
2.54.0

Re: [PATCH v2 06/13] KVM: VMX: Use higher-level allocator

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The commit message incorrectly states that `__alloc_pages_node()` allows passing `NUMA_NO_NODE`, while the opposite is true.
--

commit 7bd439c242125db27305b61b14c9972fb028282a
Author: Brendan Jackman <jackmanb@google.com>

KVM: VMX: Use higher-level allocator

This commit switches the allocation function used in alloc_vmcs_cpu()
from __alloc_pages_node() to alloc_pages_node().

> KVM: VMX: Use higher-level allocator
>
> The difference between __alloc_pages_node() and alloc_pages_node() is
> that the former allows you to pass NUMA_NO_NODE.

[Severity: Medium]
Is this description inverted?

Looking at include/linux/gfp.h, it appears __alloc_pages_node() explicitly
forbids NUMA_NO_NODE (-1) via VM_BUG_ON(nid < 0).

Instead, it is alloc_pages_node() that handles NUMA_NO_NODE by explicitly
checking for it and falling back to numa_mem_id().

While the code change itself is safe, the justification reverses the
behavior of the two APIs. Could the commit message be updated to
accurately reflect the API semantics?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260622-alloc-trylock-v2-0-31f31367d420@google.com?part=6

Re: [PATCH v2 06/13] KVM: VMX: Use higher-level allocator

[Brendan Jackman]

On Mon Jun 22, 2026 at 10:10 AM UTC, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The commit message incorrectly states that `__alloc_pages_node()` allows passing `NUMA_NO_NODE`, while the opposite is true.
> --
>
> commit 7bd439c242125db27305b61b14c9972fb028282a
> Author: Brendan Jackman <jackmanb@google.com>
>
> KVM: VMX: Use higher-level allocator
>
> This commit switches the allocation function used in alloc_vmcs_cpu()
> from __alloc_pages_node() to alloc_pages_node().
>
>> KVM: VMX: Use higher-level allocator
>>
>> The difference between __alloc_pages_node() and alloc_pages_node() is
>> that the former allows you to pass NUMA_NO_NODE.
>
> [Severity: Medium]
> Is this description inverted?
>
> Looking at include/linux/gfp.h, it appears __alloc_pages_node() explicitly
> forbids NUMA_NO_NODE (-1) via VM_BUG_ON(nid < 0).
>
> Instead, it is alloc_pages_node() that handles NUMA_NO_NODE by explicitly
> checking for it and falling back to numa_mem_id().
>
> While the code change itself is safe, the justification reverses the
> behavior of the two APIs. Could the commit message be updated to
> accurately reflect the API semantics?

Repeating myself[0] as this patch has a different CC list from the others:

Sashiko is correct, the commit message says "former" but it should say
"latter".

[0] https://lore.kernel.org/all/DJFI39RWHV1O.MMMMMZSK8E8C@linux.dev/

Re: [PATCH v2 00/13] mm: Some cleanups for page allocator APIs

[Vlastimil Babka (SUSE)]

+Cc Hao Ge for the "remove __GFP_NO_CODETAG" part

On 6/22/26 12:01, Brendan Jackman wrote:
> Some tweaks and cleanups for page allocator entrypoint and flags. This
> is motivated by preparation for __GFP_UNMAPPED [1] (which will probably
> become ALLOC_UNMAPPED in its next iteration), but all this is supposed
> to be an improvement to the codebase in its own right: unifying code
> paths, reducing API surface, and removing GFP flags.
> 
> [1] https://lore.kernel.org/all/20260320-page_alloc-unmapped-v2-0-28bf1bd54f41@google.com/
> 
> This started with unifying  __alloc_frozen_pages[_nolock]_noprof() and
> expanded from there.
> 
> Unifying the nolock allocator entrypoint with the normal allocator
> entrypoint means adding an alloc_flags argument to the later (only
> exposed within mm/). This presents an opportunity to take advantage of
> that arg to remove some GFP flags, if we add that alloc_flags arg a bit
> more broadly to allocator entrypoints.
> 
> To distinguish between mm-internal and "public" allocator entrypoints,
> it makes sense to use the __ prefix. There are already some public APIs
> with that prefix. For *alloc_pages*, just removing those variants seems
> like a nice cleanup anyway, so do that. For get_free_pages, the "__"
> variant is the _only_ variant and it's very widely used, so it doesn't
> seem worthwhile to modify that. Therefore, scope this "__" change
> specifically to the *alloc_pages* API, which means we leave the
> *folio_alloc* API untouched too, even though that could probably be
> cleaned up if so desired.
> 
> Tested:
> 
> - KVM, mm, and BPF selftests in a QEMU VM
> 
> - kunit.py on x86_64
> 
> - For the ALLOC_NO_CODETAG bits I just booted a VM and read
>   /proc/allocinfo. I confirmed that if I remove ALLOC_NO_CODETAG, the
>   kernel crashes in early boot, so I was at least booting code that
>   depends on this logic.
> 
> I used Google's internal version of Antigravity (AI coding harness) to
> do the repetitive bits, those commits are marked with Assisted-by, the
> rest is manual.
> 
> Signed-off-by: Brendan Jackman <jackmanb@google.com>
> ---
> Changes in v2:
> - Fixed up whitespace in nolock unification patch
> - Introduced ALLOC_DEFAULT to replace literal 0 for alloc_flags
> - All other patches are new
> - Link to v1: https://patch.msgid.link/20260617-alloc-trylock-v1-1-83fd7858832e@google.com
> 
> ---
> Brendan Jackman (13):
>       mm/page_alloc: rename ALLOC_TRYLOCK -> ALLOC_NOLOCK
>       mm/page_alloc: some renames to clarify alloc_flags scopes
>       mm/page_alloc: unify __alloc_frozen_pages[_nolock]_noprof()
>       mm/page_alloc: relax GFP WARN in nolock allocs
>       perf/x86/intel: Use higher-level allocator
>       KVM: VMX: Use higher-level allocator
>       x86/virt: Use higher-level allocator
>       sgi-xp: Use higher-level allocator
>       net/funeth: Switch to higher-level allocator
>       mm: Remove __alloc_pages_node()
>       alloc_tag: Move to mm/
>       mm: Move __alloc_pages() to mm/internal.h
>       mm: remove __GFP_NO_CODETAG
> 
>  Documentation/admin-guide/cgroup-v1/cpusets.rst  |   2 +-
>  Documentation/admin-guide/mm/transhuge.rst       |   2 +-
>  MAINTAINERS                                      |   2 +-
>  arch/x86/events/intel/ds.c                       |   6 +-
>  arch/x86/kvm/vmx/vmx.c                           |   2 +-
>  arch/x86/virt/hw.c                               |   2 +-
>  drivers/misc/sgi-xp/xpc_uv.c                     |   2 +-
>  drivers/net/ethernet/fungible/funeth/funeth_rx.c |   2 +-
>  include/linux/gfp.h                              |  28 +--
>  lib/Makefile                                     |   1 -
>  mm/Makefile                                      |   1 +
>  {lib => mm}/alloc_tag.c                          |  18 +-
>  mm/compaction.c                                  |   4 +-
>  mm/hugetlb.c                                     |   3 +-
>  mm/internal.h                                    |  20 +-
>  mm/mempolicy.c                                   |  10 +-
>  mm/page_alloc.c                                  | 254 +++++++++++++----------
>  mm/page_frag_cache.c                             |   4 +-
>  mm/slub.c                                        |   6 +-
>  19 files changed, 193 insertions(+), 176 deletions(-)
> ---
> base-commit: cbe5256a15fc26f592efb037e528da54b2139ee5
> change-id: 20260617-alloc-trylock-14ad37dab337
> 
> Best regards,
> --  
> Brendan Jackman <jackmanb@google.com>
> 

Re: [PATCH v2 00/13] mm: Some cleanups for page allocator APIs

[Lorenzo Stoakes]

Thanks for the series (cleanups are always welcome :) but just a gentle,
annoying, note to say it's week 2 of the merge window soooo we're not taking
anything at the moment as it's a quiet period (mm-unstable taking only fixes
AFAICT).

Though, it's potentially good to get stuff in front of people early, just an FYI
that we're trying to move towards keeping the merge window preview/RFC-only
going forwards.

I'm not sure if that'll fix the impossible review load problem (TM), but it at
least helps keep us sane re: what's actually landing/not.

So Andrew will expect you to resend this after 7.2-rc1 appears!

Thanks, Lorenzo

Re: [PATCH v2 00/13] mm: Some cleanups for page allocator APIs

[Brendan Jackman]

On Mon, 22 Jun 2026 at 15:09, Lorenzo Stoakes <ljs@kernel.org> wrote:
>
> Thanks for the series (cleanups are always welcome :) but just a gentle,
> annoying, note to say it's week 2 of the merge window soooo we're not taking
> anything at the moment as it's a quiet period (mm-unstable taking only fixes
> AFAICT).
>
> Though, it's potentially good to get stuff in front of people early, just an FYI
> that we're trying to move towards keeping the merge window preview/RFC-only
> going forwards.
>
> I'm not sure if that'll fix the impossible review load problem (TM), but it at
> least helps keep us sane re: what's actually landing/not.
>
> So Andrew will expect you to resend this after 7.2-rc1 appears!

Sorry as I discovered on [0] I am completely ignorant about merge
windows, etc. Even after that thread it never really occurred to me
that people might not want to receive patches at all when busy trying
to get the rc into shape!

Anyway in this case I'm assuming there will be at least a v3 so I'll
just wait before sending that.

[0]: https://lore.kernel.org/all/DJD12YR8S99G.1I43PSHB77TA2@linux.dev/