All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harry Yoo <harry.yoo@oracle.com>
To: Suren Baghdasaryan <surenb@google.com>
Cc: David Wang <00107082@163.com>, Vlastimil Babka <vbabka@suse.com>,
	vbabka@suse.cz, linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [7.0-rc1] codetag: kernel warning "alloc_tag was not set" during boot
Date: Tue, 24 Feb 2026 23:26:16 +0900	[thread overview]
Message-ID: <aZ21CP0d-RRAjUCX@hyeyoo> (raw)
In-Reply-To: <aZ2yrEz2ZVggT7UL@hyeyoo>

On Tue, Feb 24, 2026 at 11:16:12PM +0900, Harry Yoo wrote:
> Just sharing updates on this before going to bed...
> 
> I was able to reproduce it on my machine I have a working fix
> (nowhere close to upstream quality, though)
> 
> The reason why we're seeing "alloc_tag not was set" is
> because SLUB allocates empty sheaves for kmalloc
> with __GFP_NO_OBJ_EXT and it doesn't teach memory profiling
> how to handle this when such sheaves are freed.
> 
> When __GFP_NO_OBJ_EXT is used in alloc_slab_obj_exts(), it later
> avoids this "alloc_tag was not set" warning by marking alloc_tags
> empty in free_slab_obj_exts(), just before freeing obj_exts.
> 
> And we don't handle this when allocating freeing sheaves
> that were allocated with __GFP_NO_OBJ_EXT.
> 
> Passing __GFP_NO_OBJ_EXT skips 1) allocation of obj_exts,
> and 2) alloc_tag_add() even when obj_exts is already allocated,
> and this confuses memory profiling later.
> 
> I'm adding the fix I have now. (I guess Suren might have some preference
> on how to solve it though)
> 
>   1. mark obj_exts allocation failure when slab has no obj_exts and
>      gfp flag has __GFP_NO_OBJ_EXT, so that a later obj_exts allocation
>      will mark alloc_tags empty.
> 
>   2. Set alloc_tag when obj_exts is allocated available,
>      even when __GFP_NO_OBJ_EXT is set.
> 
>      Because it's already allocated, we don't have to worry about
>      recursive allocation.

Wait, isn't it much simpler to just do mark_objexts_empty(sheaf);
just before freeing sheaves, if s->flags has SLAB_KMALLOC?

/me goes to bed anyway

-- 
Cheers,
Harry / Hyeonggon


  reply	other threads:[~2026-02-24 14:26 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-23 15:51 [7.0-rc1] codetag: kernel warning "alloc_tag was not set" during boot David Wang
2026-02-23 17:18 ` Vlastimil Babka
2026-02-23 18:34   ` Suren Baghdasaryan
2026-02-24  1:56     ` David Wang
2026-02-24  2:15   ` Harry Yoo
2026-02-24  2:28   ` David Wang
2026-02-24  7:07     ` Suren Baghdasaryan
2026-02-24 11:15       ` David Wang
2026-02-24 14:16       ` Harry Yoo
2026-02-24 14:26         ` Harry Yoo [this message]
2026-02-24 16:15           ` Suren Baghdasaryan
2026-02-24 16:56             ` Suren Baghdasaryan
2026-02-24 22:18               ` Suren Baghdasaryan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aZ21CP0d-RRAjUCX@hyeyoo \
    --to=harry.yoo@oracle.com \
    --cc=00107082@163.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=surenb@google.com \
    --cc=vbabka@suse.com \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.