From: "Paul E. McKenney" <paulmck@kernel.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Qian Cai <quic_qiancai@quicinc.com>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@linux.com>,
David Rientjes <rientjes@google.com>,
Pekka Enberg <penberg@kernel.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Mike Galbraith <efault@gmx.de>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Thomas Gleixner <tglx@linutronix.de>,
Mel Gorman <mgorman@techsingularity.net>,
Jesper Dangaard Brouer <brouer@redhat.com>,
Jann Horn <jannh@google.com>
Subject: Re: [PATCH v4 29/35] mm: slub: Move flush_cpu_slab() invocations __free_slab() invocations out of IRQ context
Date: Tue, 10 Aug 2021 13:25:14 -0700 [thread overview]
Message-ID: <20210810202514.GA190765@paulmck-ThinkPad-P17-Gen-1> (raw)
In-Reply-To: <fbf59e73-8b27-56a8-d863-cfe40457f4df@suse.cz>
On Tue, Aug 10, 2021 at 11:03:02AM +0200, Vlastimil Babka wrote:
> On 8/9/21 3:41 PM, Qian Cai wrote:
> >>
> >> +static DEFINE_MUTEX(flush_lock);
> >> +static DEFINE_PER_CPU(struct slub_flush_work, slub_flush);
> >> +
> >> static void flush_all(struct kmem_cache *s)
> >> {
> >> - on_each_cpu_cond(has_cpu_slab, flush_cpu_slab, s, 1);
> >> + struct slub_flush_work *sfw;
> >> + unsigned int cpu;
> >> +
> >> + mutex_lock(&flush_lock);
> >
> > Vlastimil, taking the lock here could trigger a warning during memory offline/online due to the locking order:
> >
> > slab_mutex -> flush_lock
> >
> > [ 91.374541] WARNING: possible circular locking dependency detected
> > [ 91.381411] 5.14.0-rc5-next-20210809+ #84 Not tainted
> > [ 91.387149] ------------------------------------------------------
> > [ 91.394016] lsbug/1523 is trying to acquire lock:
> > [ 91.399406] ffff800018e76530 (flush_lock){+.+.}-{3:3}, at: flush_all+0x50/0x1c8
> > [ 91.407425]
> > but task is already holding lock:
> > [ 91.414638] ffff800018e48468 (slab_mutex){+.+.}-{3:3}, at: slab_memory_callback+0x44/0x280
> > [ 91.423603]
> > which lock already depends on the new lock.
From the series in -next, I got a three-way deadlock similar to what
Qian Cai got.
> OK, managed to reproduce in qemu and this fixes it for me on top of
> next-20210809. Could you test as well, as your testing might be more
> comprehensive? I will format is as a fixup for the proper patch in the series then.
>
> ----8<----
> >From 7ce71c7f9455e8b96dc1b728ea566b6ef5e424e4 Mon Sep 17 00:00:00 2001
> From: Vlastimil Babka <vbabka@suse.cz>
> Date: Tue, 10 Aug 2021 10:58:07 +0200
> Subject: [PATCH] mm, slub: fix memory offline lockdep splat
>
> Reverse order of flush_lock and cpus_read_lock() to prevent lockdep splat.
> In slab_mem_going_offline_callback() we already have cpus_read_lock()
> held so make sure it's not taken again.
>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
With this patch, it reduces to a two-way deadlock as shown at the end
of this message.
My reproducer is the following on a two-socket system:
tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration 10m --configs RUDE01 --trust-make
This likely needs the RCU commits in -next to reproduce quickly, though
you never know.
Thanx, Paul
> ---
> mm/slub.c | 27 ++++++++++++++++++++-------
> 1 file changed, 20 insertions(+), 7 deletions(-)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index 88a6c3ed2751..073cdd4b020f 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -2640,13 +2640,13 @@ static bool has_cpu_slab(int cpu, struct kmem_cache *s)
> static DEFINE_MUTEX(flush_lock);
> static DEFINE_PER_CPU(struct slub_flush_work, slub_flush);
>
> -static void flush_all(struct kmem_cache *s)
> +static void flush_all_cpus_locked(struct kmem_cache *s)
> {
> struct slub_flush_work *sfw;
> unsigned int cpu;
>
> + lockdep_assert_cpus_held();
> mutex_lock(&flush_lock);
> - cpus_read_lock();
>
> for_each_online_cpu(cpu) {
> sfw = &per_cpu(slub_flush, cpu);
> @@ -2667,10 +2667,16 @@ static void flush_all(struct kmem_cache *s)
> flush_work(&sfw->work);
> }
>
> - cpus_read_unlock();
> mutex_unlock(&flush_lock);
> }
>
> +static void flush_all(struct kmem_cache *s)
> +{
> + cpus_read_lock();
> + flush_all_cpus_locked(s);
> + cpus_read_unlock();
> +}
> +
> /*
> * Use the cpu notifier to insure that the cpu slabs are flushed when
> * necessary.
> @@ -4516,7 +4522,7 @@ EXPORT_SYMBOL(kfree);
> * being allocated from last increasing the chance that the last objects
> * are freed in them.
> */
> -int __kmem_cache_shrink(struct kmem_cache *s)
> +int __kmem_cache_do_shrink(struct kmem_cache *s)
> {
> int node;
> int i;
> @@ -4528,7 +4534,6 @@ int __kmem_cache_shrink(struct kmem_cache *s)
> unsigned long flags;
> int ret = 0;
>
> - flush_all(s);
> for_each_kmem_cache_node(s, node, n) {
> INIT_LIST_HEAD(&discard);
> for (i = 0; i < SHRINK_PROMOTE_MAX; i++)
> @@ -4578,13 +4583,21 @@ int __kmem_cache_shrink(struct kmem_cache *s)
> return ret;
> }
>
> +int __kmem_cache_shrink(struct kmem_cache *s)
> +{
> + flush_all(s);
> + return __kmem_cache_do_shrink(s);
> +}
> +
> static int slab_mem_going_offline_callback(void *arg)
> {
> struct kmem_cache *s;
>
> mutex_lock(&slab_mutex);
> - list_for_each_entry(s, &slab_caches, list)
> - __kmem_cache_shrink(s);
> + list_for_each_entry(s, &slab_caches, list) {
> + flush_all_cpus_locked(s);
> + __kmem_cache_do_shrink(s);
> + }
> mutex_unlock(&slab_mutex);
>
> return 0;
> --
> 2.32.0
[ 602.668050] ========================================================
[ 602.668924] WARNING: possible circular locking dependency detected
[ 602.669796] 5.14.0-rc5-next-20210809+ #3298 Not tainted
[ 602.670537] ------------------------------------------------------
[ 602.671408] torture_shutdow/88 is trying to acquire lock:
[ 602.672169] ffffffffb00686b0 (cpu_hotplug_lock){++++}-{0:0}, at: __kmem_=
cache_shutdown+0x26/0x210
[ 602.673416]
[ 602.673416] but task is already holding lock:
[ 602.674240] ffffffffb0178368 (slab_mutex){+.+.}-{3:3}, at: kmem_cache_de=
stroy+0x1c/0x110
[ 602.675379]
[ 602.675379] which lock already depends on the new lock.
[ 602.675379]
[ 602.676525]
[ 602.676525] the existing dependency chain (in reverse order) is:
[ 602.677576]
[ 602.677576] -> #1 (slab_mutex){+.+.}-{3:3}:
[ 602.678377] __mutex_lock+0x81/0x9a0
[ 602.678964] slub_cpu_dead+0x17/0xb0
[ 602.679547] cpuhp_invoke_callback+0x180/0x890
[ 602.680255] cpuhp_invoke_callback_range+0x3b/0x80
[ 602.681009] _cpu_down+0xe4/0x2b0
[ 602.681556] cpu_down+0x29/0x50
[ 602.682082] device_offline+0x7e/0xb0
[ 602.682677] remove_cpu+0x17/0x30
[ 602.683225] torture_offline+0x7d/0x140
[ 602.683844] torture_onoff+0x14f/0x260
[ 602.684455] kthread+0x132/0x160
[ 602.684994] ret_from_fork+0x22/0x30
[ 602.685574]
[ 602.685574] -> #0 (cpu_hotplug_lock){++++}-{0:0}:
[ 602.686460] __lock_acquire+0x13d2/0x2470
[ 602.687107] lock_acquire+0xc9/0x2e0
[ 602.687686] cpus_read_lock+0x26/0xb0
[ 602.688284] __kmem_cache_shutdown+0x26/0x210
[ 602.688973] kmem_cache_destroy+0x38/0x110
[ 602.689625] rcu_torture_cleanup.cold.36+0x192/0x421
[ 602.690399] torture_shutdown+0xdd/0x1c0
[ 602.691032] kthread+0x132/0x160
[ 602.691563] ret_from_fork+0x22/0x30
[ 602.692147]
[ 602.692147] other info that might help us debug this:
[ 602.692147]
[ 602.693268] Possible unsafe locking scenario:
[ 602.693268]
[ 602.694128] CPU0 CPU1
[ 602.694766] ---- ----
[ 602.695409] lock(slab_mutex);
[ 602.695858] lock(cpu_hotplug_lock);
[ 602.696731] lock(slab_mutex);
[ 602.697531] lock(cpu_hotplug_lock);
[ 602.698057]
[ 602.698057] *** DEADLOCK ***
[ 602.698057]
[ 602.698884] 1 lock held by torture_shutdow/88:
[ 602.699517] #0: ffffffffb0178368 (slab_mutex){+.+.}-{3:3}, at: kmem_cac=
he_destroy+0x1c/0x110
[ 602.700716]
[ 602.700716] stack backtrace:
[ 602.701334] CPU: 3 PID: 88 Comm: torture_shutdow Not tainted 5.14.0-rc5-=
next-20210809+ #3298
[ 602.702518] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.13.0-2.module_el8=
.5.0+746+bbd5d70c 04/01/2014
[ 602.703799] Call Trace:
[ 602.704160] dump_stack_lvl+0x44/0x57
[ 602.704686] check_noncircular+0xfe/0x110
[ 602.705264] __lock_acquire+0x13d2/0x2470
[ 602.705836] lock_acquire+0xc9/0x2e0
[ 602.706389] ? __kmem_cache_shutdown+0x26/0x210
[ 602.707059] cpus_read_lock+0x26/0xb0
[ 602.707582] ? __kmem_cache_shutdown+0x26/0x210
[ 602.708226] __kmem_cache_shutdown+0x26/0x210
[ 602.708843] ? lock_is_held_type+0xd6/0x130
[ 602.709442] ? torture_onoff+0x260/0x260
[ 602.710007] kmem_cache_destroy+0x38/0x110
[ 602.710590] rcu_torture_cleanup.cold.36+0x192/0x421
[ 602.711298] ? wait_woken+0x60/0x60
[ 602.711796] ? torture_onoff+0x260/0x260
[ 602.712359] torture_shutdown+0xdd/0x1c0
[ 602.712918] kthread+0x132/0x160
[ 602.713386] ? set_kthread_struct+0x40/0x40
[ 602.713985] ret_from_fork+0x22/0x30
next prev parent reply other threads:[~2021-08-10 20:25 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-05 15:19 [PATCH v4 00/35] SLUB: reduce irq disabled scope and make it RT compatible Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 01/35] mm, slub: don't call flush_all() from slab_debug_trace_open() Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 02/35] mm, slub: allocate private object map for debugfs listings Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 03/35] mm, slub: allocate private object map for validate_slab_cache() Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 04/35] mm, slub: don't disable irq for debug_check_no_locks_freed() Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 05/35] mm, slub: remove redundant unfreeze_partials() from put_cpu_partial() Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 06/35] mm, slub: unify cmpxchg_double_slab() and __cmpxchg_double_slab() Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 07/35] mm, slub: extract get_partial() from new_slab_objects() Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 08/35] mm, slub: dissolve new_slab_objects() into ___slab_alloc() Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 09/35] mm, slub: return slab page from get_partial() and set c->page afterwards Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 10/35] mm, slub: restructure new page checks in ___slab_alloc() Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 11/35] mm, slub: simplify kmem_cache_cpu and tid setup Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 12/35] mm, slub: move disabling/enabling irqs to ___slab_alloc() Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 13/35] mm, slub: do initial checks in ___slab_alloc() with irqs enabled Vlastimil Babka
2021-08-15 10:14 ` Vlastimil Babka
2021-08-15 10:22 ` Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 14/35] mm, slub: move disabling irqs closer to get_partial() in ___slab_alloc() Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 15/35] mm, slub: restore irqs around calling new_slab() Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 16/35] mm, slub: validate slab from partial list or page allocator before making it cpu slab Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 17/35] mm, slub: check new pages with restored irqs Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 18/35] mm, slub: stop disabling irqs around get_partial() Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 19/35] mm, slub: move reset of c->page and freelist out of deactivate_slab() Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 20/35] mm, slub: make locking in deactivate_slab() irq-safe Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 21/35] mm, slub: call deactivate_slab() without disabling irqs Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 22/35] mm, slub: move irq control into unfreeze_partials() Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 23/35] mm, slub: discard slabs in unfreeze_partials() without irqs disabled Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 24/35] mm, slub: detach whole partial list at once in unfreeze_partials() Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 25/35] mm, slub: separate detaching of partial list in unfreeze_partials() from unfreezing Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 26/35] mm, slub: only disable irq with spin_lock in __unfreeze_partials() Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 27/35] mm, slub: don't disable irqs in slub_cpu_dead() Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 28/35] mm, slab: make flush_slab() possible to call with irqs enabled Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 29/35] mm: slub: Move flush_cpu_slab() invocations __free_slab() invocations out of IRQ context Vlastimil Babka
2021-08-09 13:41 ` Qian Cai
2021-08-09 18:44 ` Mike Galbraith
2021-08-09 20:08 ` Vlastimil Babka
2021-08-09 22:13 ` Qian Cai
2021-08-10 1:07 ` Mike Galbraith
2021-08-10 9:03 ` Vlastimil Babka
2021-08-10 11:47 ` Mike Galbraith
2021-08-10 20:31 ` Paul E. McKenney
2021-08-10 22:36 ` Vlastimil Babka
2021-08-10 23:53 ` Paul E. McKenney
2021-08-11 14:17 ` Paul E. McKenney
2021-08-10 20:25 ` Paul E. McKenney [this message]
2021-08-10 14:33 ` Vlastimil Babka
2021-08-11 1:42 ` Qian Cai
2021-08-11 8:55 ` Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 30/35] mm: slub: Make object_map_lock a raw_spinlock_t Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 31/35] mm, slub: optionally save/restore irqs in slab_[un]lock()/ Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 32/35] mm, slub: make slab_lock() disable irqs with PREEMPT_RT Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 33/35] mm, slub: protect put_cpu_partial() with disabled irqs instead of cmpxchg Vlastimil Babka
2021-08-05 15:19 ` [PATCH v4 34/35] mm, slub: use migrate_disable() on PREEMPT_RT Vlastimil Babka
2021-08-05 15:20 ` [PATCH v4 35/35] mm, slub: convert kmem_cpu_slab protection to local_lock Vlastimil Babka
2021-08-15 12:27 ` Sven Eckelmann
2021-08-17 8:37 ` Vlastimil Babka
2021-08-17 9:12 ` Sebastian Andrzej Siewior
2021-08-17 9:17 ` Vlastimil Babka
2021-08-17 9:31 ` Sebastian Andrzej Siewior
2021-08-17 9:31 ` Vlastimil Babka
2021-08-17 9:34 ` Sebastian Andrzej Siewior
2021-08-17 9:13 ` Vlastimil Babka
2021-08-17 10:14 ` Vlastimil Babka
2021-08-17 19:53 ` Andrew Morton
2021-08-18 11:52 ` Vlastimil Babka
2021-08-23 20:36 ` Thomas Gleixner
2021-08-17 15:39 ` Sebastian Andrzej Siewior
2021-08-17 15:41 ` Vlastimil Babka
2021-08-17 15:49 ` Sebastian Andrzej Siewior
2021-08-17 15:56 ` Vlastimil Babka
2021-08-05 16:42 ` [PATCH v4 00/35] SLUB: reduce irq disabled scope and make it RT compatible Sebastian Andrzej Siewior
2021-08-06 5:14 ` Mike Galbraith
2021-08-06 7:45 ` Vlastimil Babka
2021-08-10 14:36 ` Vlastimil Babka
2021-08-15 10:18 ` Vlastimil Babka
2021-08-17 10:23 ` Vlastimil Babka
2021-08-17 15:59 ` 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=20210810202514.GA190765@paulmck-ThinkPad-P17-Gen-1 \
--to=paulmck@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bigeasy@linutronix.de \
--cc=brouer@redhat.com \
--cc=cl@linux.com \
--cc=efault@gmx.de \
--cc=iamjoonsoo.kim@lge.com \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=penberg@kernel.org \
--cc=quic_qiancai@quicinc.com \
--cc=rientjes@google.com \
--cc=tglx@linutronix.de \
--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