Re: [PATCH v2 05/13] perf/x86/intel: 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 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.

> 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?