Received: by 2002:a05:6358:bb9e:b0:b9:5105:a5b4 with SMTP id df30csp490032rwb; Fri, 2 Sep 2022 18:42:18 -0700 (PDT) X-Google-Smtp-Source: AA6agR6/HVlrSvumRC91J9bXTGvUfQyEhDjBKPrhmSmJMK4V6r+59rynWCACsbT2I8yh988pyiFU X-Received: by 2002:a17:902:b684:b0:172:d9f4:e511 with SMTP id c4-20020a170902b68400b00172d9f4e511mr38547784pls.107.1662169338160; Fri, 02 Sep 2022 18:42:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662169338; cv=none; d=google.com; s=arc-20160816; b=qBNgxj5qqGsnnhf0I84p9QFAOvemnEcxJE3XKhGlnC58Y7VB+KU8N0wQIlBaZDqmgV E+jw3NNRwljZXx8u6LrSnEHzbhXKsi1vho4wWXo4qotkeg0ZXwc/htPtFlrGK6Mch5Ta zRjJrP21rtK0XGQA83PRImsHAOGhGKZQi2Myhig8VdVSD4rI+GKei0RjCGE63oVuKRo6 h2tQHN3HD5MEAcOkRdF1QWgv8tAsMPn3D63UKTMggDcGodm6fy9KB1hZYIcyWRmD5Pen L9dD7qj2F2h+BPd55IXcAK0RK80XIlExpRcI7bTiPVJHAnhxh4hyQCC0lMYpjLV41a0V yHcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:references:in-reply-to:subject :cc:to:from:mime-version:content-transfer-encoding:dkim-signature :dkim-signature; bh=kOtyw6vlWTD4GBfJ46VsGKoxC3DDcJeFHhSL1DQkmvE=; b=ro1QnxYCR18jTN4B94PeXmfoVDO+yFpNt4PPSFuFAq5/my4PqI6g8xbWcpa7gD/HcL bT7qqZcZxqlH5Om/uA5jNlkk2btp600YsS1y7pHW0kmTXXRqxcyFWuiGcGXkL4oPYh09 Y92cuDEdOXdWujTZhsPe8tnk2LUIHVhguMMgs+mBEnQgtM34tQ/ZodHrwP/ysf98uLwj 6bzxnQbK63H25pRFiuehkyK9jb24utaJbIGVAmdshvRKc+cGhddm2bdsgG1ciQazlfR3 LodE4a94I64iAy4VEWEn935J+2DSNouhteIIot550x3Q4XDdgpnw4aHa5PNN/TWoxmHv okPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=LpKIfTv5; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t14-20020a17090340ce00b00175053442aasi3356578pld.230.2022.09.02.18.41.57; Fri, 02 Sep 2022 18:42:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=LpKIfTv5; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229905AbiICBk6 (ORCPT + 99 others); Fri, 2 Sep 2022 21:40:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40900 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229609AbiICBk4 (ORCPT ); Fri, 2 Sep 2022 21:40:56 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8F4186610F; Fri, 2 Sep 2022 18:40:55 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 5A5D85CDDD; Sat, 3 Sep 2022 01:40:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1662169253; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kOtyw6vlWTD4GBfJ46VsGKoxC3DDcJeFHhSL1DQkmvE=; b=LpKIfTv5HEWEL+Ymq+LnYUN+RHHdZOKMb+wRoNTH7fIDHsYpsokuiiZ+8xRS6DdG+pEBWL ylvZ6uaPMDc5dBgyKy9VbUcANvR3HnSDvf5y42BEI1GilGyPIL9BRubjGHRlojBbbRxQ15 PraZODD7+kzIKFuKSkBqbqruQ4O7yX4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1662169253; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kOtyw6vlWTD4GBfJ46VsGKoxC3DDcJeFHhSL1DQkmvE=; b=Z05dagcxqNBT2NgVh8n/tcwXlyfV7BzxSHQAmeuh1SCir53yg0eiDCUb17ln+pEO/QmMTu 28CdkNY1PMuuuwBQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id C4F88133A7; Sat, 3 Sep 2022 01:40:50 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id kLNgH6KwEmOBeAAAMHmgww (envelope-from ); Sat, 03 Sep 2022 01:40:50 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 From: "NeilBrown" To: "Al Viro" Cc: "Linus Torvalds" , "Daire Byrne" , "Trond Myklebust" , "Chuck Lever" , "Linux NFS Mailing List" , linux-fsdevel@vger.kernel.org, "LKML" Subject: Re: [PATCH 01/10] VFS: support parallel updates in the one directory. In-reply-to: References: <166147828344.25420.13834885828450967910.stgit@noble.brown>, <166147984370.25420.13019217727422217511.stgit@noble.brown>, , <166173834258.27490.151597372187103012@noble.neil.brown.name>, Date: Sat, 03 Sep 2022 11:40:44 +1000 Message-id: <166216924401.28768.5809376269835339554@noble.neil.brown.name> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Sat, 03 Sep 2022, Al Viro wrote: > On Mon, Aug 29, 2022 at 11:59:02AM +1000, NeilBrown wrote: > > > > When would we get out of __lookup_hash() with in-lookup dentry? > > > Confused... > > > > Whenever wq is passed in and ->lookup() decides, based on the flags, to do > > nothing. > > NFS does this for LOOKUP_CREATE|LOOKUP_EXCL and for LOOKUP_RENAME_TARGET > > Frankly, I would rather do what all other callers of ->lookup() do and > just follow it with d_lookup_done(dentry), no matter what it returns. > It's cheap enough... > I don't think that is a good idea. Once you call d_lookup_done() (without having first called d_add() or similar) the dentry becomes invisible to normal path lookup, so another might be created. But the dentry will still be used for the 'create' or 'rename' and may then be added to the dcache - at which point you could have two dentries with the same name. When ->lookup() returns success without d_add()ing the dentry, that means that something else will complete the d_add() if/when necessary. For NFS, it specifically means that the lookup is effectively being combined with the following CREATE or RENAME. In this case there is no d_lookup_done() until the full operation is complete. For autofs (thanks for pointing me to that) the operation is completed when d_automount() signals the daemon to create the directory or symlink. In that case there IS a d_lookup_done() call and autofs needs some extra magic (the internal 'active' list) to make sure subsequent ->lookup requests can see that dentry which is still in the process of being set up. It might be nice if the dentry passed to autofs_lookup() could remain "d_inlookup()" until after d_automount has completed. Then autofs wouldn't need that active list. However I haven't yet looked at how disruptive such a change might be. Thanks, NeilBrown