On Tue, 19 Feb 2013 10:14:50 +1100 NeilBrown <neilb@xxxxxxx> wrote: > On Mon, 18 Feb 2013 20:15:02 +0000 Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > On Mon, Feb 18, 2013 at 02:46:55PM -0500, Jeff Layton wrote: > > > > > Ok, that helps. In that case, this patch might be a reasonable > > > forward-port of the one Neil sent earlier today. Note that this doesn't > > > really do anything for the umount problem, but it does seem to fix the > > > testcase for the problem I've been looking at. > > > > > > Thoughts? > > > > If we really go for "in this case revalidate should be weaker", we might > > as well introduce a separate method for it. > > > > As it is, we have several callers of ->d_revalidate(); this one (in > > complete_walk(), only for FS_REVAL_DOT filesystems) and ones in > > lookup_dcache() and lookup_fast() (in both cases we have and want the > > name to match). There are only two fs with FS_REVAL_DOT present - nfs > > and 9p. *IF* we want to make ->d_revalidate() on NFS behave differently > > in complete_walk() case, it would argue for just splitting the method > > in two, replacing FS_REVAL_DOT with "dentry has this method" and probably > > taking a good look at what 9p needs in the same case. > > Sounds good to me. > > Reminds me that we used to have an i_op->revalidate() method for revalidating > just the inode (not the dentry). It called nfs_revalidate_inode() for NFS. > > We lost it over a decade ago: > > commit cc41b90f8a9ad3cd85a39dd4fcc71f965a675b0e > Author: Alexander Viro <viro@xxxxxxxxxxxx> > Date: Tue May 21 21:12:46 2002 -0700 > > [PATCH] kill ->i_op->revalidate() > > kill ->i_op->revalidate() > > > > :-) > > (this doesn't help my umount problem though) > That would work for NFS, but unfortunately I think 9p needs a dentry operation here if we're not going to break it. Anyone want to suggest a new name for it? I'm using d_reval_dot for now, but a better name would be welcome... -- Jeff Layton <jlayton@xxxxxxxxxx>
Attachment:
signature.asc
Description: PGP signature
