[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190711002527.GD17978@ZenIV.linux.org.uk>
Date: Thu, 11 Jul 2019 01:25:27 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Pavel Machek <pavel@....cz>,
kernel list <linux-kernel@...r.kernel.org>,
sfr@...b.auug.org.au
Subject: Re: next-20190708: kernel BUG at lib/lockref.c:189, softlockups in
shrink_dcache...?
On Wed, Jul 10, 2019 at 05:09:12PM -0700, Andrew Morton wrote:
> On Wed, 10 Jul 2019 22:13:11 +0200 Pavel Machek <pavel@....cz> wrote:
>
> > Hi!
> >
> > I'm getting some nastyness from lockref / memory management.
> >
> > Any ideas? Any ideas who to talk to?
> >
>
> I'd be suspecting Al's a99d7580f66e737 ("Teach shrink_dcache_parent()
> to cope with mixed-filesystem shrink lists").
It is, and it's already fixed. See 9bdebc2bd1c4 with fixes folded in;
the incremental is
diff --git a/fs/dcache.c b/fs/dcache.c
index d8732cf2e302..01b8cae41a71 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1555,7 +1555,9 @@ void shrink_dcache_parent(struct dentry *parent)
d_walk(parent, &data, select_collect2);
if (data.victim) {
struct dentry *parent;
+ spin_lock(&data.victim->d_lock);
if (!shrink_lock_dentry(data.victim)) {
+ spin_unlock(&data.victim->d_lock);
rcu_read_unlock();
} else {
rcu_read_unlock();
> This appears to have been added to -next around the -rc6 timeframe,
> which seems awfully late?
I'm not sure if I'll be asking to pull that series this window,
actually ;-/
Sigh... This cycle had been a mess - spent a month or so very unpleasantly
sick ;-/
Powered by blists - more mailing lists