From: Vlastimil Babka <vbabka@suse.cz>
To: Rongwei Wang <rongwei.wang@linux.alibaba.com>,
Christoph Lameter <cl@linux.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
David Rientjes <rientjes@google.com>,
Pekka Enberg <penberg@kernel.org>
Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
linux-mm@kvack.org,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Thomas Gleixner <tglx@linutronix.de>,
Mike Galbraith <efault@gmx.de>, Vlastimil Babka <vbabka@suse.cz>
Subject: [PATCH v2 3/5] mm/slub: remove slab_lock() usage for debug operations
Date: Tue, 23 Aug 2022 19:03:58 +0200 [thread overview]
Message-ID: <20220823170400.26546-4-vbabka@suse.cz> (raw)
In-Reply-To: <20220823170400.26546-1-vbabka@suse.cz>
All alloc and free operations on debug caches are now serialized by
n->list_lock, so we can remove slab_lock() usage in validate_slab()
and list_slab_objects() as those also happen under n->list_lock.
Note the usage in list_slab_objects() could happen even on non-debug
caches, but only during cache shutdown time, so there should not be any
parallel freeing activity anymore. Except for buggy slab users, but in
that case the slab_lock() would not help against the common cmpxchg
based fast paths (in non-debug caches) anyway.
Also adjust documentation comments accordingly.
Suggested-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Acked-by: David Rientjes <rientjes@google.com>
---
mm/slub.c | 19 ++++++++-----------
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
index a5a913879871..b4065e892f7c 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -50,7 +50,7 @@
* 1. slab_mutex (Global Mutex)
* 2. node->list_lock (Spinlock)
* 3. kmem_cache->cpu_slab->lock (Local lock)
- * 4. slab_lock(slab) (Only on some arches or for debugging)
+ * 4. slab_lock(slab) (Only on some arches)
* 5. object_map_lock (Only for debugging)
*
* slab_mutex
@@ -64,8 +64,9 @@
* The slab_lock is a wrapper around the page lock, thus it is a bit
* spinlock.
*
- * The slab_lock is only used for debugging and on arches that do not
- * have the ability to do a cmpxchg_double. It only protects:
+ * The slab_lock is only used on arches that do not have the ability
+ * to do a cmpxchg_double. It only protects:
+ *
* A. slab->freelist -> List of free objects in a slab
* B. slab->inuse -> Number of objects in use
* C. slab->objects -> Number of objects in slab
@@ -94,6 +95,9 @@
* allocating a long series of objects that fill up slabs does not require
* the list lock.
*
+ * For debug caches, all allocations are forced to go through a list_lock
+ * protected region to serialize against concurrent validation.
+ *
* cpu_slab->lock local lock
*
* This locks protect slowpath manipulation of all kmem_cache_cpu fields
@@ -4368,7 +4372,6 @@ static void list_slab_objects(struct kmem_cache *s, struct slab *slab,
void *p;
slab_err(s, slab, text, s->name);
- slab_lock(slab, &flags);
map = get_map(s, slab);
for_each_object(p, s, addr, slab->objects) {
@@ -4379,7 +4382,6 @@ static void list_slab_objects(struct kmem_cache *s, struct slab *slab,
}
}
put_map(map);
- slab_unlock(slab, &flags);
#endif
}
@@ -5107,12 +5109,9 @@ static void validate_slab(struct kmem_cache *s, struct slab *slab,
{
void *p;
void *addr = slab_address(slab);
- unsigned long flags;
-
- slab_lock(slab, &flags);
if (!check_slab(s, slab) || !on_freelist(s, slab, NULL))
- goto unlock;
+ return;
/* Now we know that a valid freelist exists */
__fill_map(obj_map, s, slab);
@@ -5123,8 +5122,6 @@ static void validate_slab(struct kmem_cache *s, struct slab *slab,
if (!check_object(s, slab, p, val))
break;
}
-unlock:
- slab_unlock(slab, &flags);
}
static int validate_slab_node(struct kmem_cache *s,
--
2.37.2
next prev parent reply other threads:[~2022-08-23 17:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-23 17:03 [PATCH v2 0/5] mm/slub: fix validation races and cleanup locking Vlastimil Babka
2022-08-23 17:03 ` [PATCH v2 1/5] mm/slub: move free_debug_processing() further Vlastimil Babka
2022-08-23 17:03 ` [PATCH v2 2/5] mm/slub: restrict sysfs validation to debug caches and make it safe Vlastimil Babka
2022-08-24 4:41 ` Hyeonggon Yoo
2022-08-23 17:03 ` Vlastimil Babka [this message]
2022-08-23 17:03 ` [PATCH v2 4/5] mm/slub: convert object_map_lock to non-raw spinlock Vlastimil Babka
2022-08-24 15:53 ` Sebastian Andrzej Siewior
2022-08-23 17:04 ` [PATCH v2 5/5] mm/slub: simplify __cmpxchg_double_slab() and slab_[un]lock() Vlastimil Babka
2022-08-24 10:24 ` Hyeonggon Yoo
2022-08-24 11:51 ` Vlastimil Babka
2022-08-24 12:45 ` Hyeonggon Yoo
2022-08-24 16:31 ` Sebastian Andrzej Siewior
2022-08-24 13:04 ` Hyeonggon Yoo
2022-08-25 12:41 ` Vlastimil Babka
2022-08-24 16:25 ` Sebastian Andrzej Siewior
2022-08-25 12:59 ` Vlastimil Babka
2022-08-25 7:51 ` [PATCH 6/5] slub: Make PREEMPT_RT support less convoluted Sebastian Andrzej Siewior
2022-08-25 8:41 ` Vlastimil Babka
2022-08-25 8:49 ` Hyeonggon Yoo
2022-08-25 13:16 ` [PATCH v2 0/5] mm/slub: fix validation races and cleanup locking Vlastimil Babka
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=20220823170400.26546-4-vbabka@suse.cz \
--to=vbabka@suse.cz \
--cc=42.hyeyoo@gmail.com \
--cc=bigeasy@linutronix.de \
--cc=cl@linux.com \
--cc=efault@gmx.de \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=rongwei.wang@linux.alibaba.com \
--cc=tglx@linutronix.de \
/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.