[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180414080206.GV30522@ZenIV.linux.org.uk>
Date: Sat, 14 Apr 2018 09:02:06 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: Nikolay Borisov <nborisov@...e.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Khazhismel Kumykov <khazhy@...gle.com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
David Rientjes <rientjes@...gle.com>,
Goldwyn Rodrigues <rgoldwyn@...e.de>,
Jeff Mahoney <jeffm@...e.com>,
Davidlohr Bueso <dave@...olabs.net>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] fs/dcache.c: re-add cond_resched() in
shrink_dcache_parent()
On Sat, Apr 14, 2018 at 10:00:29AM +0300, Nikolay Borisov wrote:
>
>
> On 14.04.2018 00:14, Andrew Morton wrote:
> > On Fri, 13 Apr 2018 13:28:23 -0700 Khazhismel Kumykov <khazhy@...gle.com> wrote:
> >
> >> shrink_dcache_parent may spin waiting for a parallel shrink_dentry_list.
> >> In this case we may have 0 dentries to dispose, so we will never
> >> schedule out while waiting for the parallel shrink_dentry_list to
> >> complete.
> >>
> >> Tested that this fixes syzbot reports of stalls in shrink_dcache_parent()
> >
> > Well I guess the patch is OK as a stopgap, but things seem fairly
> > messed up in there. shrink_dcache_parent() shouldn't be doing a
> > busywait, waiting for the concurrent shrink_dentry_list().
> >
> > Either we should be waiting (sleeping) for the concurrent operation to
> > complete or we should just bail out of shrink_dcache_parent(), perhaps
> > with
> >
> > if (list_empty(&data.dispose))
> > break;
> >
> > or similar. Dunno.
>
> I agree, however, not being a dcache expert I'd refrain from touching
> it, since it seems to be rather fragile. Perhaps Al could take a look in
> there?
"Bail out" is definitely a bad idea, "sleep"... what on? Especially
since there might be several evictions we are overlapping with...
Powered by blists - more mailing lists