Re: [PATCH] dcache: fix d_splice_alias handling of aliases

[J. Bruce Fields]

On Thu, Jan 16, 2014 at 04:15:42PM +0000, Steven Whitehouse wrote:
> Hi,
> 
> On Thu, 2014-01-16 at 11:10 -0500, J. Bruce Fields wrote:
> > On Wed, Jan 15, 2014 at 10:17:49AM -0500, bfields wrote:
> > > From: "J. Bruce Fields" <bfields@xxxxxxxxxx>
> > > 
> > > d_splice_alias can create duplicate directory aliases (in the !new
> > > case), or (in the new case) d_move without holding appropriate locks.
> > > 
> > > d_materialise_unique deals with both of these problems.  (The latter
> > > seems to be dealt by trylocks (see __d_unalias), which look like they
> > > could cause spurious lookup failures--but that's at least better than
> > > corrupting the dcache.)
> > > 
> > > Signed-off-by: J. Bruce Fields <bfields@xxxxxxxxxx>
> > > ---
> > >  fs/dcache.c |   25 +------------------------
> > >  1 file changed, 1 insertion(+), 24 deletions(-)
> > > 
> > > Only lightly tested....  If this is right, then we can also just ditch
> > > d_splice_alias completely, and clean up the various d_find_alias's.
> > > 
> > > I think the only reason we have both d_splice_alias and
> > > d_materialise_unique is that the former was written for exportable
> > > filesystems and the latter for distributed filesystems.
> > > 
> > > But we have at least one exportable filesystem (fuse) using
> > > d_materialise_unique.  And I doubt d_splice_alias was ever completely
> > > correct even for on-disk filesystems.
> > > 
> > > Am I missing some subtlety?
> > 
> > Hm, I just noticed:
> > 
> >     commit 0d0d110720d7960b77c03c9f2597faaff4b484ae
> >     Author: Miklos Szeredi <mszeredi@xxxxxxx>
> >     Date:   Mon Sep 16 14:52:00 2013 +0200
> > 
> >     GFS2: d_splice_alias() can't return error
> >     
> >     unless it was given an IS_ERR(inode), which isn't the case here.  So clean
> >     up the unnecessary error handling in gfs2_create_inode().
> >     
> >     This paves the way for real fixes (hence the stable Cc).
> >     
> >     Signed-off-by: Miklos Szeredi <mszeredi@xxxxxxx>
> >     Signed-off-by: Steven Whitehouse <swhiteho@xxxxxxxxxx>
> >     Cc: stable@xxxxxxxxxxxxxxx
> > 
> > While the statement is true for the current implementation of
> > d_splice_alias, I don't think it's actually true for any correct
> > implementation of d_splice_alias, which must be able to return at least
> > -ELOOP in the directory case.  Does gfs2 need fixing?
> > 
> > --b.
> 
> Yes, in that case, probably in two places,

Something like this?

(Except: is the inode cleanup right in the first chunk?  And in the
second chunk the cleanup could maybe be organized better even if I got
it right....)

--b.

diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c
index 7119504..19e0924 100644
--- a/fs/gfs2/inode.c
+++ b/fs/gfs2/inode.c
@@ -585,6 +585,9 @@ static int gfs2_create_inode(struct inode *dir, struct dentry *dentry,
 	error = PTR_ERR(inode);
 	if (!IS_ERR(inode)) {
 		d = d_splice_alias(inode, dentry);
+		error = PTR_ERR(d);
+		if (IS_ERR(d))
+			goto fail_gunlock;
 		error = 0;
 		if (file) {
 			if (S_ISREG(inode->i_mode)) {
@@ -779,6 +782,11 @@ static struct dentry *__gfs2_lookup(struct inode *dir, struct dentry *dentry,
 	}
 
 	d = d_splice_alias(inode, dentry);
+	if (IS_ERR(d)) {
+		iput(inode);
+		gfs2_glock_dq_uninit(&gh);
+		return ERR_PTR(error);
+	}
 	if (file && S_ISREG(inode->i_mode))
 		error = finish_open(file, dentry, gfs2_open_common, opened);
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/