Re: [PATCH v2 13/13] mm: remove __GFP_NO_CODETAG

[Brendan Jackman]

On Tue Jun 23, 2026 at 7:56 AM UTC, Hao Ge wrote:
> Hi Brendan
>
>
> On 2026/6/22 18:01, Brendan Jackman wrote:
>> Now that alloc_pages has an entrypoint that allows passing alloc_flags,
>> we can take advantage of this to start removing GFP flags that are only
>> used for mm-internal stuff.
>>
>> This requires also plumbing the alloc_flags into some more of the
>> allocator code, in particular __alloc_pages[_noprof]() gets an
>> alloc_flags arg to go along with its callees, and we now need to pass
>> those flags deeper into the allocator so they can reach the alloc_tag
>> code.
>>
>> To try and keep the new ALLOC_NO_CODETAG's scope nice and narrow, don't
>> define it in mm/internal.h, instead just define a "reserved bit" and
>> then use that in places that don't care about what it means.
>>
>> Signed-off-by: Brendan Jackman <jackmanb@xxxxxxxxxx>
>
>
> Nit: The title says "remove __GFP_NO_CODETAG" but the flag isn't really 
> removed — it's migrated from gfp_t to alloc_flags as
>
> ALLOC_NO_CODETAG. Something like "mm: replace __GFP_NO_CODETAG with an 
> alloc_flag" would be more accurate.

Good point, will reword this.

> Additionally, as Lorenzo pointed out in another thread, you will likely 
> need to rebase this series later.
>
> I noticed Vlastimil has already landed the slab changes removing 
> __GFP_NO_OBJ_EXT into mainline:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=335c347686e76df9d2c7d7f61b5ea627a4c5cb4c
>
> For v3, it might make sense to fold in Vlastimil's patch so the full 
> removal of __GFP_NO_OBJ_EXT can be completed end-to-end
>
> https://lore.kernel.org/all/20260609-slab_alloc_flags-v1-15-2bf4a4b9b526@xxxxxxxxxx/

Ack, thanks for the links and review!