[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFxD1xKqbobvoHQUWc5jc9n7-7KXYeSQy-CpE0SUZHi0PQ@mail.gmail.com>
Date: Sat, 14 Apr 2018 14:47:21 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Nikolay Borisov <nborisov@...e.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Khazhismel Kumykov <khazhy@...gle.com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux Kernel Mailing List <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>
Subject: Re: [PATCH] fs/dcache.c: re-add cond_resched() in shrink_dcache_parent()
On Sat, Apr 14, 2018 at 1:58 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> That breaks d_invalidate(), unfortunately. Look at the termination
> conditions in the loop there...
Ugh. I was going to say "but that doesn't even use select_collect()",
but yeah, detach_and_collect() calls it.
It would be easy enough to just change the
if (!list_empty(&data.select.dispose))
there to
if (!list_empty(&data.select.found))
too.
In fact, it probably *should* do that, exactly to get the whole
"cond_resched()" call in that whole call chain too. Because as-is, it
looks like it has the same issue as shrink_dcache_parent() does..
But yeah, the fact that I didn't notice that makes me a bit nervous.
But now I triple-checked, there are no other indirect callers.
Linus
Powered by blists - more mailing lists