From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755301AbcGERmM (ORCPT ); Tue, 5 Jul 2016 13:42:12 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:41652 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751407AbcGERmK (ORCPT ); Tue, 5 Jul 2016 13:42:10 -0400 Date: Tue, 5 Jul 2016 18:42:08 +0100 From: Al Viro To: Oleg Drokin Cc: Mailing List , "" Subject: Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes. Message-ID: <20160705174207.GN14480@ZenIV.linux.org.uk> References: <20160617042914.GD14480@ZenIV.linux.org.uk> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73CF0170-DE2B-4335-91EE-D7EE41069BFA@linuxhacker.ru> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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?