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

[Severity: Medium]
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?

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