Re: [PATCH v3 1/1] mm/slab: mark alloc tags empty for sheaves allocated with __GFP_NO_OBJ_EXT

[Vlastimil Babka (SUSE)]

On 2/25/26 22:28, Suren Baghdasaryan wrote:
> On Wed, Feb 25, 2026 at 9:23 PM Vlastimil Babka <vbabka@xxxxxxxx> wrote:
>>
>> On 2/25/26 8:08 PM, Suren Baghdasaryan wrote:
>> > On Wed, Feb 25, 2026 at 4:34 PM Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote:
>> >>
>> >> alloc_empty_sheaf() allocates sheaves from SLAB_KMALLOC caches using
>> >> __GFP_NO_OBJ_EXT to avoid recursion, however it does not mark their
>> >> allocation tags empty before freeing, which results in a warning when
>> >> CONFIG_MEM_ALLOC_PROFILING_DEBUG is set. Fix this by marking allocation
>> >> tags for such sheaves as empty.
>> >>
>> >
>> > I think this should also have:
>> >
>> > Fixes: 4c0a17e28340 ("slab: prevent recursive kmalloc() in alloc_empty_sheaf()")
>> >
>> > and CC to stable for inclusion into 6.19.
>> > Andrew, Vlastimil, should I post another version CC'ing stable or you
>> > can add that line and forward to stable?
>>
>> I will add it. Note, they don't care about getting an actual email, but
>> seeing the Cc: line in the mainline commit.
> 
> Perfect! Thank you. Let me know if anything else is needed on my end.

I tried to cherry-pick it to 6.19 stable and there were conflicts so I
think it's easier to just remove the Cc stable. Instead I updated the
changelog/trailer to contain:

    The problem was technically introduced in commit 4c0a17e28340 but only
    becomes possible to hit with commit 913ffd3a1bf5.
    
    Fixes: 4c0a17e28340 ("slab: prevent recursive kmalloc() in alloc_empty_sheaf()")
    Fixes: 913ffd3a1bf5 ("slab: handle kmalloc sheaves bootstrap")
    Reported-by: David Wang <00107082@xxxxxxx>
    ...

Added to slab/for-next-fixes, thanks!

>>
>> >> Reported-by: David Wang <00107082@xxxxxxx>
>> >> Closes: https://lore.kernel.org/all/20260223155128.3849-1-00107082@xxxxxxx/
>> >> Analyzed-by: Harry Yoo <harry.yoo@xxxxxxxxxx>
>> >> Signed-off-by: Suren Baghdasaryan <surenb@xxxxxxxxxx>
>> >> Reviewed-by: Harry Yoo <harry.yoo@xxxxxxxxxx>
>> >> Tested-by: Harry Yoo <harry.yoo@xxxxxxxxxx>
>> >> Tested-by: David Wang <00107082@xxxxxxx>