From: "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
To: Steven Whitehouse <swhiteho-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Miklos Szeredi <mszeredi-AlSwsSmVLrQ@public.gmane.org>
Subject: Re: [PATCH] dcache: fix d_splice_alias handling of aliases
Date: Thu, 16 Jan 2014 11:44:11 -0500 [thread overview]
Message-ID: <20140116164411.GD16829@fieldses.org> (raw)
In-Reply-To: <1389888942.2779.34.camel@menhir>
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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > >
> > > 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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > > ---
> > > 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-AlSwsSmVLrQ@public.gmane.org>
> > 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-AlSwsSmVLrQ@public.gmane.org>
> > Signed-off-by: Steven Whitehouse <swhiteho-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.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-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-01-16 16:44 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-15 15:17 [PATCH] dcache: fix d_splice_alias handling of aliases J. Bruce Fields
2014-01-15 17:34 ` Miklos Szeredi
2014-01-15 17:57 ` J. Bruce Fields
[not found] ` <20140115175723.GA4596-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2014-01-15 18:25 ` Miklos Szeredi
2014-01-16 15:41 ` J. Bruce Fields
[not found] ` <20140116154132.GB16829-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2014-01-16 16:13 ` Miklos Szeredi
[not found] ` <20140115151749.GF23999-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2014-01-16 16:10 ` J. Bruce Fields
2014-01-16 16:15 ` Steven Whitehouse
2014-01-16 16:44 ` J. Bruce Fields [this message]
2014-01-16 16:54 ` Bob Peterson
2014-01-16 18:51 ` J. Bruce Fields
2014-01-17 10:04 ` Steven Whitehouse
2014-01-17 18:04 ` J. Bruce Fields
2014-01-17 12:17 ` Christoph Hellwig
[not found] ` <20140117121723.GA18375-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2014-01-17 15:39 ` J. Bruce Fields
[not found] ` <20140117153917.GA26636-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2014-01-17 21:03 ` J. Bruce Fields
[not found] ` <20140117210343.GD26636-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2014-01-17 21:26 ` J. Bruce Fields
2014-01-23 21:27 ` [PATCH] dcache: make d_splice_alias use d_materialise_unique J. Bruce Fields
2014-01-31 18:42 ` Al Viro
2014-01-31 19:47 ` J. Bruce Fields
[not found] ` <20140131194758.GA24618-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2014-02-06 17:03 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140116164411.GD16829@fieldses.org \
--to=bfields-uc3wqj2krung9huczpvpmw@public.gmane.org \
--cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mszeredi-AlSwsSmVLrQ@public.gmane.org \
--cc=swhiteho-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).