Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.

Path	csiph.com!news.mixmin.net!aioe.org!gothmog.csi.it!bofh.it!news.nic.it!robomod
From	Al Viro <viro@ZenIV.linux.org.uk>
Newsgroups	linux.kernel
Subject	Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.
Date	Tue, 05 Jul 2016 19:50:02 +0200
Message-ID	<rRCDU-5Ws-13@gated-at.bofh.it> (permalink)
References	<rKTgu-1Aj-5@gated-at.bofh.it> <rKTzP-1Kz-1@gated-at.bofh.it> <rNYMF-7KV-7@gated-at.bofh.it> <rQJep-5my-5@gated-at.bofh.it> <rRs1P-7yT-11@gated-at.bofh.it> <rRxNU-2Nz-31@gated-at.bofh.it> <rRz3k-3vi-19@gated-at.bofh.it> <rRAsp-4Ci-15@gated-at.bofh.it>
MIME-Version	1.0
Content-Type	text/plain; charset=us-ascii
Content-Disposition	inline
User-Agent	Mutt/1.6.0 (2016-04-01)
Sender	robomod@news.nic.it
List-ID	<linux-kernel.vger.kernel.org>
X-Mailing-List	linux-kernel@vger.kernel.org
Approved	robomod@news.nic.it
Lines	29
Organization	linux.* mail to news gateway
X-Original-Cc	Mailing List <linux-kernel@vger.kernel.org>, "<linux-fsdevel@vger.kernel.org>" <linux-fsdevel@vger.kernel.org>
X-Original-Date	Tue, 5 Jul 2016 18:42:08 +0100
X-Original-Message-ID	<20160705174207.GN14480@ZenIV.linux.org.uk>
X-Original-References	<F861E78B-00C3-4F17-A10D-C9FCB81D43B9@linuxhacker.ru> <20160617042914.GD14480@ZenIV.linux.org.uk> <FCD75A55-A1BE-48FD-8E90-E9DFFD4DFD99@linuxhacker.ru> <20160703062917.GG14480@ZenIV.linux.org.uk> <94F1587A-7AFC-4B48-A0FC-F4CE152F18CC@linuxhacker.ru> <20160705123110.GL14480@ZenIV.linux.org.uk> <20160705135149.GM14480@ZenIV.linux.org.uk> <73CF0170-DE2B-4335-91EE-D7EE41069BFA@linuxhacker.ru>
X-Original-Sender	linux-kernel-owner@vger.kernel.org
Xref	csiph.com linux.kernel:1437213

Show key headers only | View raw

On Tue, Jul 05, 2016 at 11:21:32AM -0400, Oleg Drokin wrote:
> > ...
> > -       if (d_unhashed(*de)) {
> > +       if (d_in_lookup(*de)) {
> >                 struct dentry *alias;
> >  
> >                 alias = ll_splice_alias(inode, *de);
> 
> This breaks Lustre because we now might progress further in this function
> without calling into ll_splice_alias and that's the only place that we do
> ll_d_init() that later code depends on so we violently crash next time
> we call e.g. d_lustre_revalidate() further down that code.

Huh?  How the hell do those conditions differ there?

> Also I still wonder what's to stop d_alloc_parallel() from returning
> a hashed dentry with d_in_lookup() still true?

The fact that such dentries do not exist at any point?

> Certainly there's a big gap between hashing the dentry and dropping the PAR
> bit in there that I imagine might allow __d_lookup_rcu() to pick it up
> in between?--

WTF?  Where do you see that gap?  in-lookup dentries get hashed only in one
place - __d_add().  And there (besides holding ->d_lock around both) we
drop that bit in flags *before* _d_rehash().  AFAICS, the situation with
barriers is OK there, due to lockref_get_not_dead() serving as ACQUIRE
operation; I could be missing something subtle, but a wide gap...  Where?

Thread

csiph-web