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 1/3] mm/slub: fix the race between validate_slab and slab_free
Date: Tue, 12 Jul 2022 10:28:05 +0800 [thread overview]
Message-ID: <20220712022807.44113-1-rongwei.wang@linux.alibaba.com> (raw)
In use cases where allocating and freeing slab frequently, some
error messages, such as "Left Redzone overwritten", "First byte
0xbb instead of 0xcc" would be printed when validating slabs.
That's because an object has been filled with SLAB_RED_INACTIVE,
but has not been added to slab's freelist. And between these
two states, the behaviour of validating slab is likely to occur.
Actually, it doesn't mean the slab can not work stably. But, these
confusing messages will disturb slab debugging more or less.
Signed-off-by: Rongwei Wang <rongwei.wang@linux.alibaba.com>
---
mm/slub.c | 43 +++++++++++++++++++++++++------------------
1 file changed, 25 insertions(+), 18 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
index b1281b8654bd..e950d8df8380 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1391,18 +1391,16 @@ static noinline int free_debug_processing(
void *head, void *tail, int bulk_cnt,
unsigned long addr)
{
- struct kmem_cache_node *n = get_node(s, slab_nid(slab));
void *object = head;
int cnt = 0;
- unsigned long flags, flags2;
+ unsigned long flags;
int ret = 0;
depot_stack_handle_t handle = 0;
if (s->flags & SLAB_STORE_USER)
handle = set_track_prepare();
- spin_lock_irqsave(&n->list_lock, flags);
- slab_lock(slab, &flags2);
+ slab_lock(slab, &flags);
if (s->flags & SLAB_CONSISTENCY_CHECKS) {
if (!check_slab(s, slab))
@@ -1435,8 +1433,7 @@ static noinline int free_debug_processing(
slab_err(s, slab, "Bulk freelist count(%d) invalid(%d)\n",
bulk_cnt, cnt);
- slab_unlock(slab, &flags2);
- spin_unlock_irqrestore(&n->list_lock, flags);
+ slab_unlock(slab, &flags);
if (!ret)
slab_fix(s, "Object at 0x%p not freed", object);
return ret;
@@ -3330,7 +3327,7 @@ static void __slab_free(struct kmem_cache *s, struct slab *slab,
{
void *prior;
- int was_frozen;
+ int was_frozen, to_take_off = 0;
struct slab new;
unsigned long counters;
struct kmem_cache_node *n = NULL;
@@ -3341,14 +3338,23 @@ static void __slab_free(struct kmem_cache *s, struct slab *slab,
if (kfence_free(head))
return;
- if (kmem_cache_debug(s) &&
- !free_debug_processing(s, slab, head, tail, cnt, addr))
- return;
+ n = get_node(s, slab_nid(slab));
+ if (kmem_cache_debug(s)) {
+ int ret;
- do {
- if (unlikely(n)) {
+ spin_lock_irqsave(&n->list_lock, flags);
+ ret = free_debug_processing(s, slab, head, tail, cnt, addr);
+ if (!ret) {
spin_unlock_irqrestore(&n->list_lock, flags);
- n = NULL;
+ return;
+ }
+ }
+
+ do {
+ if (unlikely(to_take_off)) {
+ if (!kmem_cache_debug(s))
+ spin_unlock_irqrestore(&n->list_lock, flags);
+ to_take_off = 0;
}
prior = slab->freelist;
counters = slab->counters;
@@ -3369,8 +3375,6 @@ static void __slab_free(struct kmem_cache *s, struct slab *slab,
new.frozen = 1;
} else { /* Needs to be taken off a list */
-
- n = get_node(s, slab_nid(slab));
/*
* Speculatively acquire the list_lock.
* If the cmpxchg does not succeed then we may
@@ -3379,8 +3383,10 @@ static void __slab_free(struct kmem_cache *s, struct slab *slab,
* Otherwise the list_lock will synchronize with
* other processors updating the list of slabs.
*/
- spin_lock_irqsave(&n->list_lock, flags);
+ if (!kmem_cache_debug(s))
+ spin_lock_irqsave(&n->list_lock, flags);
+ to_take_off = 1;
}
}
@@ -3389,8 +3395,9 @@ static void __slab_free(struct kmem_cache *s, struct slab *slab,
head, new.counters,
"__slab_free"));
- if (likely(!n)) {
-
+ if (likely(!to_take_off)) {
+ if (kmem_cache_debug(s))
+ spin_unlock_irqrestore(&n->list_lock, flags);
if (likely(was_frozen)) {
/*
* The list lock was not taken therefore no list
--
2.27.0
next 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 Rongwei Wang [this message]
2022-07-12 2:28 ` [PATCH v2 2/3] mm/slub: improve consistency of nr_slabs count Rongwei Wang
2022-07-12 2:28 ` [PATCH v2 3/3] mm/slub: delete confusing pr_err when debugging slub Rongwei Wang
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-1-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