Re: [PATCH v2 12/13] mm: Move __alloc_pages() to mm/internal.h

[Suren Baghdasaryan]

On Tue, Jun 23, 2026 at 2:40 AM Hao Ge <hao.ge@xxxxxxxxx> wrote:
>
>
> On 2026/6/23 17:30, Brendan Jackman wrote:
> > On Tue Jun 23, 2026 at 6:50 AM UTC, Hao Ge wrote:
> >> Hi Brendan
> >>
> >>
> >> On 2026/6/22 19:14, Brendan Jackman wrote:
> >>> On Mon Jun 22, 2026 at 10:21 AM UTC, sashiko-bot wrote:
> >>>> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> >>>> - [Low] Missing EXPORT_SYMBOL for out-of-line alloc_pages_node_noprof() causes widespread module linker errors.
> >>>> --
> >>>>
> >>>> commit 42f7742177beb0066c00a7aa081250feb5859171
> >>>> Author: Brendan Jackman <jackmanb@xxxxxxxxxx>
> >>>>
> >>>> mm: Move __alloc_pages() to mm/internal.h
> >>>>
> >>>> This commit moves the __alloc_pages() family of internal functions to
> >>>> mm/internal.h to restrict them to the mm subsystem. It also moves
> >>>> alloc_pages_node_noprof() out-of-line into mm/page_alloc.c since it
> >>>> depends on __alloc_pages_noprof().
> >>>>
> >>>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> >>>>> index 36f0d625a4390..38238203ef7b0 100644
> >>>>> --- a/mm/page_alloc.c
> >>>>> +++ b/mm/page_alloc.c
> >>>> [ ... ]
> >>>>
> >>>>> @@ -5419,6 +5419,17 @@ struct page *__alloc_pages_noprof(gfp_t gfp, unsigned int order,
> >>>>>    }
> >>>>>    EXPORT_SYMBOL(__alloc_pages_noprof);
> >>>> [Severity: Low]
> >>>> Since __alloc_pages_noprof() is no longer visible outside of mm/, should this
> >>>> EXPORT_SYMBOL be removed?
> >>> Yep.
> >>>
> >>>>> +struct page *alloc_pages_node_noprof(int nid, gfp_t gfp_mask, unsigned int order)
> >>>>> +{
> >>>>> + if (nid == NUMA_NO_NODE)
> >>>>> +         nid = numa_mem_id();
> >>>>> +
> >>>>> + VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
> >>>>> + warn_if_node_offline(nid, gfp_mask);
> >>>>> +
> >>>>> + return __alloc_pages_noprof(gfp_mask, order, nid, NULL);
> >>>>> +}
> >>>> [Severity: Low]
> >>>> Does this code cause module linker errors? alloc_pages_node_noprof() is called
> >>>> by the alloc_pages_node() macro in include/linux/gfp.h, but it does not have
> >>>> an EXPORT_SYMBOL.
> >>> Yep. Doesn't show up in defconfig but if you set CONFIG_BLK_DEV_UBLK=m
> >>> then:
> >>>
> >>> ERROR: modpost: "alloc_pages_node_noprof" [drivers/block/ublk_drv.ko] undefined!
> >> I was about to report this linker issue myself, but Sashiko caught it first.
> >>
> >> While testing your patch on top of mm-new, I hit the exact same modpost
> >>
> >> undefined symbol error as mentioned above:
> >>
> >>     MODPOST Module.symvers
> >> ERROR: modpost: "alloc_pages_node_noprof" [arch/x86/kvm/kvm-intel.ko]
> >> undefined!
> >> ERROR: modpost: "alloc_pages_node_noprof" [arch/x86/kvm/kvm-amd.ko]
> >> undefined!
> >> ERROR: modpost: "alloc_pages_node_noprof" [drivers/gpu/drm/ttm/ttm.ko]
> >> undefined!
> >> ERROR: modpost: "alloc_pages_node_noprof" [drivers/misc/sgi-xp/xpc.ko]
> >> undefined!
> >> ERROR: modpost: "alloc_pages_node_noprof" [drivers/misc/sgi-gru/gru.ko]
> >> undefined!
> >> ERROR: modpost: "alloc_pages_node_noprof"
> >> [drivers/net/ethernet/amazon/ena/ena.ko] undefined!
> >> ERROR: modpost: "alloc_pages_node_noprof"
> >> [drivers/net/ethernet/amd/xgbe/amd-xgbe.ko] undefined!
> >> ERROR: modpost: "alloc_pages_node_noprof"
> >> [drivers/net/ethernet/aquantia/atlantic/atlantic.ko] undefined!
> >> ERROR: modpost: "alloc_pages_node_noprof"
> >> [drivers/net/ethernet/chelsio/cxgb4/cxgb4.ko] undefined!
> >> ERROR: modpost: "alloc_pages_node_noprof"
> >> [drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf.ko] undefined!
> >> WARNING: modpost: suppressed 14 unresolved symbol warnings because there
> >> were too many)
> > FWIW something like this happened on a previous patchset of mine, and
> > someone was like "so you just sent patches without any testing huh?" so
> > I just wanna note: I did test this (see cover letter for details) I just
> > don't bother with modules!
>
>
> No worries, this is quite common. I've run into the same thing in
>
> my own work — missing =m configs in test builds happens to everyone.
>
> It doesn't affect my testing of this series.

Building allmodconfig before posting the series is a good idea. I was
bitten by this enough times that it's on my pre-posting checklist.

>
>
> > Anyway, this is the 2nd time I've sent a patch that breaks the build of
> > CONFIG_KVM_INTEL=m so I guess it's time to add a new build to my test
> > scripts :)
> >
>