From: Nikita Danilov <Nikita@Namesys.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16525.1100.432660.844335@laputa.namesys.com>
Date: Mon, 26 Apr 2004 16:45:00 +0400
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, viro@parcelfarce.linux.theplanet.co.uk,
       trondmy@trondhjem.org, neilb@cse.unsw.edu.au
Subject: Re: d_splice_alias() problem.
In-Reply-To: <20040423164936.390462fb.akpm@osdl.org>
References: <16521.5104.489490.617269@laputa.namesys.com>
	<20040423164936.390462fb.akpm@osdl.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1692
Lines: 41

Andrew Morton writes:
 > Nikita Danilov <Nikita@Namesys.COM> wrote:
 > >
 > > for some time I am observing that during stress tests over NFS
 > > 
 > >     shrink_slab->...->prune_dcache()->prune_one_dentry()->...->iput()
 > > 
 > >  is called on inode with ->i_nlink == 0 which results in truncate and
 > >  file deletion. This is wrong in general (file system is re-entered), and
 > >  deadlock prone on some file systems.
 > 
 > The filesystem is only reentered if the caller of __alloc_pages() passed in
 > __GFP_FS, in which case the bug is in the caller, not in shrink_slab().

Well, I always thought that the only file system IO that GFP_FS is
expected to do is one issued by ->writepage. Doing truncate from within
VM scanner looks... wrong. But that's not the point, actually. Current
d_splice_alias leads to the following problems with NFS (and may be
other remote file systems also):

 * there are more dentries than nlinks for a given file, as a result

 * file (not opened by user) is not truncated when its last name is
   removed. inode is pinned in the memory indefinitely by remaining
   disconnected dentries.

 * sequence "touch x; rm x" always creates _two_ dentries for "x": one
   disconnected (by ->decode_fh) and one connected (by lookup_one_len
   from nfs unlink request).

I think that d_splice_alias() should be changed to scan inode->i_dentry
list and d_move() any disconnected dentry found into new one.

 > 

Nikita.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/