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" <bfie...@redhat.com>
> > >
> > > 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 <bfie...@redhat.com>
> > > ---
> > > 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 <mszer...@suse.cz>
> > 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 <mszer...@suse.cz>
> > Signed-off-by: Steven Whitehouse <swhit...@redhat.com>
> > Cc: sta...@vger.kernel.org
> >
> > 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
