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

[Brendan Jackman]

On Wed Jun 24, 2026 at 4:47 PM UTC, Suren Baghdasaryan wrote:
> On Tue, Jun 23, 2026 at 12:57 AM Hao Ge <hao.ge@xxxxxxxxx> 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.
>
> I don't understand why you want to narrow down visibility of one of
> the alloc_flag bits. We don't do that for any other flags, and this
> seems like an unnecessary complexity.

OK can drop this and just expose it directly.

This was just coz __GFP_NO_CODETAG was local to the .c file and it felt
like a "regression" to "leak" it into the header. But yeah on the other
hand this "reserved bit" thing is unncessary indirection.

>> > 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.
>>
>>
>> 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/
>
> I think Vlastimil's patch will be merged before this one, so this
> patch could remove __GFP_NO_OBJ_EXT complely, saying that its last
> user (__GFP_NO_CODETAG) is gone.

Yup, Vlastimil's other patches went directly to Linus so the final
__GFP_NO_OBJ_EXT removal is already  in my local branch for the v3 :)