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:16:12 +0900	[thread overview]
Message-ID: <aZ2yrEz2ZVggT7UL@hyeyoo> (raw)
In-Reply-To: <CAJuCfpEsykCarj6_k5T9EeLDfsA0fFL182g1hQ+tb-7EM=izsw@mail.gmail.com>

On Mon, Feb 23, 2026 at 11:07:08PM -0800, Suren Baghdasaryan wrote:
> On Mon, Feb 23, 2026 at 6:28 PM David Wang <00107082@163.com> wrote:
> >
> >
> > At 2026-02-24 01:18:32, "Vlastimil Babka" <vbabka@suse.com> wrote:
> > >On 2/23/26 16:51, David Wang wrote:
> > >> Hi,
> > >>
> > >> When upgrade to 7.0.0-rc1, caught a kernel WARN during boot:
> > >
> > >Would this possibly help? (it probably shouldn't but let's see)
> > >https://lore.kernel.org/all/20260223075809.19265-1-harry.yoo@oracle.com/
> > >
> >
> > Hi,
> > I tried this patch, but sadly, it doesn't help with the warning on my system...
> 
> Unfortunately I can't boot far enough with your config to get that warning.
> 
> You might be able to track down which allocation does not get its tag
> by first checking for current->alloc_tag==NULL inside
> __alloc_tagging_slab_alloc_hook() and dump the stack if that happens.
> If there are no hits (which is probably what will happen) you can do
> the same while checking for obj_exts==NULL. I suspect that condition
> will hit multiple times and one of those will likely be the cause of
> this warning. I'll look into this more tomorrow if the cause is not
> found by then.

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.

diff --git a/mm/slub.c b/mm/slub.c
index c7c8b660a994..4dbdfcd46771 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2060,8 +2060,6 @@ static inline void mark_objexts_empty(struct slabobj_ext *obj_exts)
 			return;
 		}
 
-		/* codetag should be NULL here */
-		WARN_ON(ext->ref.ct);
 		set_codetag_empty(&ext->ref);
 		put_slab_obj_exts(slab_exts);
 	}
@@ -2361,6 +2359,7 @@ __alloc_tagging_slab_alloc_hook(struct kmem_cache *s, void *object, gfp_t flags)
 	unsigned long obj_exts;
 	struct slabobj_ext *obj_ext;
 	struct slab *slab;
+	unsigned int obj_idx;
 
 	if (!object)
 		return;
@@ -2368,26 +2367,36 @@ __alloc_tagging_slab_alloc_hook(struct kmem_cache *s, void *object, gfp_t flags)
 	if (s->flags & (SLAB_NO_OBJ_EXT | SLAB_NOLEAKTRACE))
 		return;
 
-	if (flags & __GFP_NO_OBJ_EXT)
-		return;
-
 	slab = virt_to_slab(object);
+	if (flags & __GFP_NO_OBJ_EXT) {
+		obj_exts = slab_obj_exts(slab);
+		if (!obj_exts) {
+			mark_failed_objexts_alloc(slab);
+			return;
+		} else {
+			goto tag_add;
+		}
+	}
+
 	obj_exts = prepare_slab_obj_exts_hook(s, slab, flags, object);
 	/*
 	 * Currently obj_exts is used only for allocation profiling.
 	 * If other users appear then mem_alloc_profiling_enabled()
 	 * check should be added before alloc_tag_add().
 	 */
-	if (obj_exts) {
-		unsigned int obj_idx = obj_to_index(s, slab, object);
-
-		get_slab_obj_exts(obj_exts);
-		obj_ext = slab_obj_ext(slab, obj_exts, obj_idx);
-		alloc_tag_add(&obj_ext->ref, current->alloc_tag, s->size);
-		put_slab_obj_exts(obj_exts);
-	} else {
+	if (!obj_exts) {
 		alloc_tag_set_inaccurate(current->alloc_tag);
+		return;
 	}
+
+tag_add:
+	obj_idx = obj_to_index(s, slab, object);
+
+	get_slab_obj_exts(obj_exts);
+	obj_ext = slab_obj_ext(slab, obj_exts, obj_idx);
+	alloc_tag_add(&obj_ext->ref, current->alloc_tag, s->size);
+	put_slab_obj_exts(obj_exts);
+	return;
 }
 
 static inline void

-- 
Cheers,
Harry / Hyeonggon


  parent reply	other threads:[~2026-02-24 14:16 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 [this message]
2026-02-24 14:26         ` Harry Yoo
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=aZ2yrEz2ZVggT7UL@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.