lkml.org 
[lkml]   [2013]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [vfsmounts] WARNING: CPU: 1 PID: 479 at fs/dcache.c:385 d_lru_del()
On Sat, Nov 09, 2013 at 05:19:31AM +0000, Al Viro wrote:
> 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 <viro@zeniv.linux.org.uk>
> > 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...

Thanks! I can confirm that it fixed the bug.

Tested-by: Fengguang Wu <fengguang.wu@intel.com>

> 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;


\
 
 \ /
  Last update: 2013-11-10 11:21    [W:0.211 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site