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

[Suren Baghdasaryan]

On Thu, Feb 26, 2026 at 1:40 AM Vlastimil Babka (SUSE)
<vbabka@xxxxxxxxxx> wrote:
>
> 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.

Ack. Thanks!

>
>     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>