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

["Brendan Jackman" <brendan.jackman@linux.dev>]

On Mon Jun 29, 2026 at 4:02 PM UTC, sashiko-bot wrote:
> 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. 

LOL, Sashiko is correct, I did not actually delete __GFP_NO_OBJ_EXT in
this patch.