Re: [PATCH v2 05/13] perf/x86/intel: Use higher-level allocator

[Suren Baghdasaryan]

On Mon, Jun 22, 2026 at 3:20 AM Brendan Jackman
<brendan.jackman@xxxxxxxxx> wrote:
>
> 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 factually misrepresents the API differences between `__alloc_pages_node()` and `alloc_pages_node()`.
> > --
> >
> > commit a5667683e56825d97c5814c0349e4de3300e3e14
> > Author: Brendan Jackman <jackmanb@xxxxxxxxxx>
> >
> > perf/x86/intel: Use higher-level allocator
> >
> > This commit switches the memory allocation in dsalloc_pages() from
> > __alloc_pages_node() to the higher-level alloc_pages_node() function.
> > It also updates a comment to reflect the API change.
> >
> >> The difference between __alloc_pages_node() and alloc_pages_node() is
> >> that the former allows you to pass NUMA_NO_NODE.
>             ^^^^^^
>     Sashiko is correct, that should say "latter".
> >
> > [Severity: Medium]
>
> Seems like an inflated severity rating, this is basically a typo in the
> commit mesage, and anyone that noticed it would probably have realised
> what happened.

With the fix of that "extremely medium severity issue",

Reviewed-by: Suren Baghdasaryan <surenb@xxxxxxxxxx>

>
> > Is this description of the API differences accurate?
> >
> > Looking at include/linux/gfp.h, it appears the capabilities are actually
> > reversed. alloc_pages_node() is the function that explicitly supports
> > and safely handles NUMA_NO_NODE:
> >
> > include/linux/gfp.h:alloc_pages_node_noprof() {
> >     if (nid == NUMA_NO_NODE)
> >         nid = numa_mem_id();
> >     ...
> > }
> >
> > Meanwhile, __alloc_pages_node() expects a valid node ID and contains a
> > VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES) check, which will crash if
> > passed NUMA_NO_NODE.
> >
> > Could the commit message be updated to clarify that alloc_pages_node()
> > is the API that safely handles NUMA_NO_NODE?
>