From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zeniv.linux.org.uk ([195.92.253.2]:42038 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753295AbcGESIn (ORCPT ); Tue, 5 Jul 2016 14:08:43 -0400 Date: Tue, 5 Jul 2016 19:08:41 +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: <20160705180841.GO14480@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> <6D633478-6B94-465E-84D7-C0BA59C5E5F5@linuxhacker.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6D633478-6B94-465E-84D7-C0BA59C5E5F5@linuxhacker.ru> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Jul 05, 2016 at 12:33:09PM -0400, Oleg Drokin wrote: > This also makes me question the whole thing some more. We are definitely in lookup > when this hits, so the dentry is already new, yet it does not check off as > d_in_lookup(). That also means that by skipping the ll_splice_alias we are failing > to hash it and that causing needless lookups later? > Looking some back into the history of commits, d_in_lookup() is to tell us > that we are in the middle of lookup. How can we be in the middle of lookup > path then and not have this set on a dentry? We know dentry was not > substituted with anything here because we did not call into ll_split_alias(). > So what's going on then? Lookup in directory locked exclusive, that's what... In unlink(), in your testcase. And yes, this piece of 1/3 is incorrect; what I do not understand is the logics of what you are doing with dcache in ll_splice_alias() and in its caller ;-/