From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932997AbcGESMm (ORCPT ); Tue, 5 Jul 2016 14:12:42 -0400 Received: from linuxhacker.ru ([217.76.32.60]:50598 "EHLO fiona.linuxhacker.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751951AbcGESMl convert rfc822-to-8bit (ORCPT ); Tue, 5 Jul 2016 14:12:41 -0400 Subject: Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Oleg Drokin In-Reply-To: <20160705174207.GN14480@ZenIV.linux.org.uk> Date: Tue, 5 Jul 2016 14:12:37 -0400 Cc: Mailing List , "" Content-Transfer-Encoding: 8BIT Message-Id: <53902B2E-10E5-4CC1-B05B-D962D3C69FC5@linuxhacker.ru> 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> <20160705174207.GN14480@ZenIV.linux.org.uk> To: Al Viro X-Mailer: Apple Mail (2.1283) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Jul 5, 2016, at 1:42 PM, Al Viro wrote: > 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? Like explained in my other email, because this is in a normal lookup path, we can get here with a new dentry that was allocated in __hash_lookup via d_alloc (not parallel) that's not marked with the PAR bit. >> 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? Oh! I see, I missed that __d_add drops the PAR bit as well, not just the code at the end of the call that does d_alloc_parallel. Then indeed there is no gap, sorry for the false alarm.