Re: [PATCH v3 16/16] mm: remove the __GFP_NO_OBJ_EXT flag

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Incomplete removal of `__GFP_NO_OBJ_EXT` flag leaves the bit reserved in the core kernel.
--

commit d2006cc547e302003b4c27943f81bc40cdd90223
Author: Brendan Jackman <jackmanb@google.com>

mm: remove the __GFP_NO_OBJ_EXT flag

This commit removes the __GFP_NO_OBJ_EXT flag from the tools copy of
gfp_types.h. Its previous users have been converted to use
SLAB_ALLOC_NO_RECURSE or ALLOC_NO_CODETAG instead.

> diff --git a/tools/include/linux/gfp_types.h b/tools/include/linux/gfp_types.h
> index 6c75df30a281d..a93b8bd200b76 100644
> --- a/tools/include/linux/gfp_types.h
> +++ b/tools/include/linux/gfp_types.h
> @@ -55,7 +55,6 @@ enum {
>  #ifdef CONFIG_LOCKDEP
>  	___GFP_NOLOCKDEP_BIT,
>  #endif
> -	___GFP_NO_OBJ_EXT_BIT,

[Severity: Medium]
Is it possible that the core kernel header updates were missed? The
changes in this patch only modify the tools copy of the header, which
causes it to diverge from the actual kernel definitions.

Looking at include/linux/gfp_types.h, ___GFP_NO_OBJ_EXT_BIT remains
reserved in the core kernel. Additionally, the trace event mapping
TRACE_GFP_EM(NO_OBJ_EXT) is left behind as dead code in
include/trace/events/mmflags.h.

Could the removal be applied to those files as well so the bit is fully
freed in the core kernel page allocator as described in the commit
message?

>  	___GFP_LAST_BIT
>  };

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