Re: [PATCH v3 05/16] mm/page_alloc: unify __alloc_frozen_pages[_nolock]_noprof()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Spurious allocation failures for ALLOC_NOLOCK on fragmented systems
--

commit e9001ddaf8c952ebe08e5042f720b09e0b4a5da8
Author: Brendan Jackman <jackmanb@xxxxxxxxxx>

mm/page_alloc: unify __alloc_frozen_pages[_nolock]_noprof()

This commit unifies the core allocator entry points by pulling the ALLOC_NOLOCK
control up into __alloc_frozen_pages_noprof(). It turns the nolock variant
into a thin wrapper that just sets the ALLOC_NOLOCK flag and handles
NUMA_NO_NODE.

> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index a3ba63c7f9199..8d409d075e3e9 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c

[ ... ]

> @@ -5310,9 +5384,9 @@ struct page *__alloc_frozen_pages_noprof(gfp_t gfp, unsigned int order,
>  	fastpath_alloc_flags |= alloc_flags_nofragment(zonelist_zone(ac.preferred_zoneref), gfp);
>  	fastpath_alloc_flags |= alloc_flags_nonblocking(gfp, order) & ALLOC_HIGHATOMIC;
>  
> -	/* First allocation attempt */
> +	/* First allocation attempt (or, for nolock, only attempt) */
>  	page = get_page_from_freelist(alloc_gfp, order, fastpath_alloc_flags, &ac);
> -	if (likely(page))
> +	if (likely(page) || (alloc_flags & ALLOC_NOLOCK))
>  		goto out;

[Severity: High]
Could this lead to spurious allocation failures for ALLOC_NOLOCK requests
on fragmented systems?

In the pre-patch code, alloc_frozen_pages_nolock_noprof() bypassed
alloc_flags_nofragment(), allowing it to successfully steal pages from
other migratetypes when its preferred migratetype was empty.

The new unified __alloc_frozen_pages_noprof() fastpath unconditionally
applies the ALLOC_NOFRAGMENT policy to fastpath_alloc_flags. When the
requested migratetype is empty, __rmqueue() respects this flag by
skipping __rmqueue_steal() and returning NULL.

Since normal allocations fall back to the slowpath (which clears
ALLOC_NOFRAGMENT and retries), they succeed. However, ALLOC_NOLOCK
explicitly bails out after the first attempt here, permanently failing the
allocation. This might cause systems using bpf or tracing facilities under
memory fragmentation to silently drop allocations when hit from atomic
contexts.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629-alloc-trylock-v3-0-57bef0eadbc2@xxxxxxxxxx?part=5