From: Rongwei Wang <rongwei.wang@linux.alibaba.com>
To: akpm@linux-foundation.org, vbabka@suse.cz, 42.hyeyoo@gmail.com,
roman.gushchin@linux.dev, iamjoonsoo.kim@lge.com,
rientjes@google.com, penberg@kernel.org, cl@gentwo.de
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: [PATCH v2 3/3] mm/slub: delete confusing pr_err when debugging slub
Date: Tue, 12 Jul 2022 10:28:07 +0800 [thread overview]
Message-ID: <20220712022807.44113-3-rongwei.wang@linux.alibaba.com> (raw)
In-Reply-To: <20220712022807.44113-1-rongwei.wang@linux.alibaba.com>
The n->nr_slabs will be updated when really to allocate or
free a slab, but this slab is unnecessarily in full list
or partial list of one node. That means the total count of
slab in node's full and partial list is unnecessarily equal
to n->nr_slabs, even though flush_all() has been called.
An example here, an error message likes below will be
printed when 'slabinfo -v' is executed:
SLUB: kmemleak_object 4157 slabs counted but counter=4161
SLUB: kmemleak_object 4072 slabs counted but counter=4077
SLUB: kmalloc-2k 19 slabs counted but counter=20
SLUB: kmalloc-2k 12 slabs counted but counter=13
SLUB: kmemleak_object 4205 slabs counted but counter=4209
Here, deleting this pr_err() directly.
Signed-off-by: Rongwei Wang <rongwei.wang@linux.alibaba.com>
---
mm/slub.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
index 587416e39292..cdac004f232f 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -5059,11 +5059,6 @@ static int validate_slab_node(struct kmem_cache *s,
validate_slab(s, slab, obj_map);
count++;
}
- if (count != atomic_long_read(&n->nr_slabs)) {
- pr_err("SLUB: %s %ld slabs counted but counter=%ld\n",
- s->name, count, atomic_long_read(&n->nr_slabs));
- slab_add_kunit_errors();
- }
out:
spin_unlock_irqrestore(&n->list_lock, flags);
--
2.27.0
next prev parent reply other threads:[~2022-07-12 2:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-12 2:28 [PATCH v2 1/3] mm/slub: fix the race between validate_slab and slab_free Rongwei Wang
2022-07-12 2:28 ` [PATCH v2 2/3] mm/slub: improve consistency of nr_slabs count Rongwei Wang
2022-07-12 2:28 ` Rongwei Wang [this message]
2022-07-12 2:57 ` [PATCH v2 1/3] mm/slub: fix the race between validate_slab and slab_free Rongwei Wang
2022-07-13 10:22 ` Hyeonggon Yoo
2022-07-13 12:10 ` Rongwei Wang
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=20220712022807.44113-3-rongwei.wang@linux.alibaba.com \
--to=rongwei.wang@linux.alibaba.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.de \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox