Re: [PATCH v5 06/18] mm/page_alloc: relax GFP WARN in nolock allocs

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The kernel-doc comment for the public API `alloc_pages_nolock` was not updated to reflect the relaxed GFP flags.
--

commit 311d28c3e8fc444b6e80f8dca47557fd6cfebc1f
Author: Brendan Jackman <jackmanb@xxxxxxxxxx>

mm/page_alloc: relax GFP WARN in nolock allocs

This commit relaxes the VM_WARN_ON_ONCE check in nolock allocations to
allow flags included in gfp_nolock. It updates the validation to permit
callers to provide a wider set of flags safely.

Link: https://lore.kernel.org/linux-mm/ajS96fWbG4dzP3u3@xxxxxxxxxxxxxxxxxxxx/

> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index f47a848555077..c2839959d7908 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5355,7 +5355,8 @@ struct page *__alloc_frozen_pages_noprof(gfp_t gfp, unsigned int order,
>  		return NULL;
>  
>  	if (alloc_flags & ALLOC_NOLOCK) {
> -		VM_WARN_ON_ONCE(gfp & ~__GFP_ACCOUNT);
> +		/* Certain other flags could be supported later if needed. */
> +		VM_WARN_ON_ONCE(gfp & ~(__GFP_ACCOUNT | gfp_nolock));

[Severity: Low]
Does the kernel-doc comment for alloc_pages_nolock() also need to be
updated to reflect this relaxation?

Currently in mm/page_alloc.c, the documentation still states:

 * @gfp_flags: GFP flags. Only __GFP_ACCOUNT allowed.

This might mislead callers who refer to the API documentation into
believing they can strictly only pass __GFP_ACCOUNT, even though the
implementation now permits other flags included in gfp_nolock.

>  		if (!alloc_nolock_allowed())
>  			return NULL;
>  		gfp |= gfp_nolock;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-alloc-trylock-v5-0-c87b714e19d3@xxxxxxxxxx?part=6