From: Xin Long <lucien.xin@gmail.com>
To: Juri Lelli <juri.lelli@redhat.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org, Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Antoine Tenart <atenart@kernel.org>,
Clark Williams <williams@redhat.com>
Subject: Re: [PATCH] mm: slub: fix a deadlock warning in kmem_cache_destroy
Date: Tue, 18 Jan 2022 16:00:51 +0800 [thread overview]
Message-ID: <CADvbK_eKRNpE7PkdFLQgmfEme5LgEVDK7WakUc-Rj4XTRSpdiQ@mail.gmail.com> (raw)
In-Reply-To: <20220117131304.pdc3mfdowkzovw6q@localhost.localdomain>
On Mon, Jan 17, 2022 at 9:13 PM Juri Lelli <juri.lelli@redhat.com> wrote:
>
> Hi,
>
> On 17/01/22 13:40, Vlastimil Babka wrote:
> > +CC Clark
> >
> > On 1/17/22 10:33, Sebastian Andrzej Siewior wrote:
> > > On 2022-01-17 16:32:46 [+0800], Xin Long wrote:
> > >> another issue. From the code analysis, this issue does exist on the
> > >> upstream kernel, though I couldn't build an upstream RT kernel for the
> > >> testing.
> > >
> > > This should also reproduce in v5.16 since the commit in question is
> > > there.
> >
> > Yeah. I remember we had some issues with the commit during development, but
> > I'd hope those were resolved and the commit that's ultimately merged got the
> > fixes, see this subthread:
> >
> > https://lore.kernel.org/all/0b36128c-3e12-77df-85fe-a153a714569b@quicinc.com/
> >
> > >> > > CPU0 CPU1
> > >> > > ---- ----
> > >> > > cpus_read_lock()
> > >> > > kn->active++
> > >> > > cpus_read_lock() [a]
> > >> > > wait until kn->active == 0
> > >> > >
> > >> > > Although cpu_hotplug_lock is a RWSEM, [a] will not block in there. But as
> > >> > > lockdep annotations are added for cpu_hotplug_lock, a deadlock warning
> > >> > > would be detected:
> > >
> > > The cpu_hotplug_lock is a per-CPU RWSEM. The lock in [a] will block if
> > > there is a writer pending.
> > >
> > >> > > ======================================================
> > >> > > WARNING: possible circular locking dependency detected
> > >> > > ------------------------------------------------------
> > >> > > dmsetup/1832 is trying to acquire lock:
> > >> > > ffff986f5a0f9f20 (kn->count#144){++++}-{0:0}, at: kernfs_remove+0x1d/0x30
> > >> > >
> > >> > > but task is already holding lock:
> > >> > > ffffffffa43817c0 (slab_mutex){+.+.}-{3:3}, at: kmem_cache_destroy+0x2a/0x120
> > >> > >
> > >
> > > I tried to create & destroy a cryptarget which creates/destroy a cache
> > > via bio_put_slab(). Either the callchain is different or something else
> > > is but I didn't see a lockdep warning.
> >
> > RHEL-8 kernel seems to be 4.18, unless RT uses a newer one. Could be some
> > silently relevant backport is missing? How about e.g. 59450bbc12be ("mm,
> > slab, slub: stop taking cpu hotplug lock") ?
>
> Hummm, looks like we have backported commit 59450bbc12be in RHEL-8.
>
> Xin Long, would you be able to check if you still see the lockdep splat
> with latest upstream RT?
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git linux-5.16.y-rt
Hi, Juri,
Thanks for sharing the RT kernel repo.
I just tried with this kernel, and I couldn't reproduce it on my env.
But I don't see how the upstream RT kernel can avoid the call trace.
As this warning was triggered when the system was shutting down, it might
not be reproduced on it due to some timing change.
>
> Thanks!
> Juri
>
next prev parent reply other threads:[~2022-01-18 8:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-14 14:23 [PATCH] mm: slub: fix a deadlock warning in kmem_cache_destroy Xin Long
2022-01-16 6:35 ` Hyeonggon Yoo
2022-01-17 8:32 ` Xin Long
2022-01-17 9:33 ` Sebastian Andrzej Siewior
2022-01-17 12:40 ` Vlastimil Babka
2022-01-17 13:13 ` Juri Lelli
2022-01-18 8:00 ` Xin Long [this message]
2022-01-18 11:07 ` Vlastimil Babka
2022-01-19 8:38 ` Xin Long
2022-06-01 14:36 ` Maurizio Lombardi
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=CADvbK_eKRNpE7PkdFLQgmfEme5LgEVDK7WakUc-Rj4XTRSpdiQ@mail.gmail.com \
--to=lucien.xin@gmail.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=atenart@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=vbabka@suse.cz \
--cc=williams@redhat.com \
/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;
as well as URLs for NNTP newsgroup(s).