From: Al Viro <viro@ZenIV.linux.org.uk>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-nfs@vger.kernel.org, Miklos Szeredi <mszeredi@suse.cz>
Subject: Re: [PATCH] dcache: make d_splice_alias use d_materialise_unique
Date: Fri, 31 Jan 2014 18:42:58 +0000 [thread overview]
Message-ID: <20140131184258.GN10323@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20140123212700.GA30466@fieldses.org>
On Thu, Jan 23, 2014 at 04:27:00PM -0500, J. Bruce Fields wrote:
> From: "J. Bruce Fields" <bfields@redhat.com>
>
> d_splice_alias can create duplicate directory aliases (in the !new
> case), or (in the new case) d_move directories without holding
> appropriate locks.
Details, please. In the new case, we have IS_ROOT() alias found;
what locks would that need? Note that d_materialise_unique() won't
bother with __d_unalias() in such case - it does what d_move() would've
done, without taking any mutex.
In the !new case, we'd need a preexisting dentry alias, complete with
parent. IOW, that's the case when directory already in the tree
has been found during lookup from another parent. In which case
we shouldn't be using d_splice_alias() at all, as it is (and it
certainly can't happen for any local fs).
Now, I agree that merging that with d_materialise_unique() might be
a good idea, but commit message is wrong as it, AFAICS.
next prev parent reply other threads:[~2014-01-31 18:43 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
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 [this message]
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=20140131184258.GN10323@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=bfields@fieldses.org \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=mszeredi@suse.cz \
/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).