From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [vfsmounts] WARNING: CPU: 1 PID: 479 at fs/dcache.c:385 d_lru_del() Date: Sat, 9 Nov 2013 05:19:31 +0000 Message-ID: <20131109051931.GT13318@ZenIV.linux.org.uk> References: <20131109030636.GA13464@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Fengguang Wu Return-path: Content-Disposition: inline In-Reply-To: <20131109030636.GA13464@localhost> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Sat, Nov 09, 2013 at 11:06:36AM +0800, Fengguang Wu wrote: > Greetings, > > I got the below dmesg and the first bad commit is > > commit 84550b9356af50c7cbd6b6ce6e8fd06585eebf14 > Author: Al Viro > Date: Sun Sep 29 22:06:07 2013 -0400 Got it... See if the following fixes the problem - it's shrink_dcache_for_umount() needing to be careful after possible run of d_genocide(); we are left with dentries that have zero refcount and are not on any LRU. And yes, it's d_genocide() being not nice, exactly because it relies upon shrink_dcache_for_umount() coming right after it to sweep the garbage. So we'd better be ready to deal with said garbage... Diff below fixes that junk here. Folded and re-pushed... diff --git a/fs/dcache.c b/fs/dcache.c index 50d4357..72c99b8 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -1391,7 +1391,8 @@ static enum d_walk_ret umount_collect(void *_data, struct dentry *dentry) * need to get the global LRU lock and do the * LRU accounting. */ - d_lru_del(dentry); + if (dentry->d_flags & DCACHE_LRU_LIST) + d_lru_del(dentry); d_shrink_add(dentry, &data->dispose); data->found++; ret = D_WALK_NORETRY;