From nobody Wed Jun 17 07:22:57 2026 Received: from fhigh-a5-smtp.messagingengine.com (fhigh-a5-smtp.messagingengine.com [103.168.172.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8D21D23EAB3; Mon, 27 Apr 2026 04:05:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.156 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262754; cv=none; b=jcPHO1KA9ozpf8+HCcipvXMnhXQPOJ2/DaebN4SwxBFAQwOkAIEpQdAj8ME+g+CAzU35puBO217P477ttPDSLfHiRBNxdRXO42cQ5t1JJ9Zs5BCplESPpoWKzr+nqTf0b2DUQlcM3chQbuanaslrrLT/ytkwtoK5LkEASz6YoFs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262754; c=relaxed/simple; bh=DELTMxF9kP8S3D0HUlogd9b5wHyCedqPjH1ZMIOOcJw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Q7mvsqWBy0mt4I+vi1MyFSlFj1JsBNn2Rr7zTXx1+Jt59tOm3Nthsem+ATBN3GNrXeVA28aVavvTO1ZL/IhFDoXEBxwXk2Yywbt8h7mGGFM9CqtCsRT1qJcWgWA9jU1vv3A2qrEg/oub83vTJlx+7hv43ElN5xC/gR89y/lOpfI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net; spf=pass smtp.mailfrom=ownmail.net; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b=FCvElu+j; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=vAl8PIAC; arc=none smtp.client-ip=103.168.172.156 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ownmail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b="FCvElu+j"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="vAl8PIAC" Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfhigh.phl.internal (Postfix) with ESMTP id D2D3614000CC; Mon, 27 Apr 2026 00:05:52 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Mon, 27 Apr 2026 00:05:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ownmail.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to; s=fm2; t=1777262752; x=1777349152; bh=/9kQHGI58tF58bk2NGiFwIvwHRvIsc6zHHG5MNu+tic=; b= FCvElu+j97cUJ0XsJ3wORmDhnLXRMxpEfRY0wBp2OdME0OPpjb9YNwi7ENIJSEsp Lue2/zg7Uu15zjB0kGOoc1LsI4edu+xjXm4omN2vOEMdgh7RE68b61d1Z7P8ux9T UcR0C3y0QrGz4a/uQzrejvU4GMGAIKHrZfzQzcnA834XDsL98RPJt3FRRIHmMXih hfcQMZ7SZ0XaLseZ9fPvkceqHVxzG+DIPkSw9BfTIphQurZq+n/CdB4xNuSVQdAv +MRerVjuI1E8rYOnD0zuGbsb46laW0aSwwKjbofzyC2+Y1zpTXyrikWUxhavO1nS PeQ78rDTlhNMRs09hELviQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1777262752; x=1777349152; bh=/ 9kQHGI58tF58bk2NGiFwIvwHRvIsc6zHHG5MNu+tic=; b=vAl8PIAC/pTGs8By4 tPfJ8G8O3bjF7fl/IT0c7RGQ68tYdqATNj8Dha1Qgcp5bJUO5I3Memh0o3hvv7n4 7mAIvSSgTr5So51QGemaH+KzvsTOw67uLBzLEQkHOPKmxxKzrxkYh2JIpYOE/ePJ VgB8/ORrpWL58Thtw/uFFpIp51Fr7vTyq1MVoQo+3s3fb9W/NC30LYcOOJrC+DBO xYDjpvPJCaz2PmbDXy+p7O/ixvdEEuujI7U2gEza9RaZQ6tHbCNChP4iRVkBo5Hv 4S3dU5LN9lEuxr/dr4VLN6fS+qLjW0LBrL+7XMNt9CRyu8p2nHESd6QaYc/xcWZ+ AVLMw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdejjeeikecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffkffojghfrhgggfestdekredtredttdenucfhrhhomheppfgvihhluehr ohifnhcuoehnvghilhgssehofihnmhgrihhlrdhnvghtqeenucggtffrrghtthgvrhhnpe evveekffduueevhfeigefhgfdukedtleekjeeitdejudfgueekvdekffdvfedvudenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhgsse hofihnmhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeduiedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvhhirhhoseiivghnihhvrdhlihhnuhigrdhorhhgrdhukhdprh gtphhtthhopehlihhnuhigqdhunhhiohhnfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhg pdhrtghpthhtoheplhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprh gtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehlihhnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehmihhklhhoshesshiivghrvgguihdrhhhupdhrtghpthhtohepjhgrtg hksehsuhhsvgdrtgiipdhrtghpthhtohepjhhksehoiihlrggsshdrohhrgh X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Apr 2026 00:05:48 -0400 (EDT) From: NeilBrown To: Linus Torvalds , Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Trond Myklebust , Anna Schumaker , Miklos Szeredi , Amir Goldstein , Jeremy Kerr , Ard Biesheuvel Cc: linux-efi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 01/19] VFS: fix various typos in documentation for start_creating start_removing etc Date: Mon, 27 Apr 2026 14:01:19 +1000 Message-ID: <20260427040517.828226-2-neilb@ownmail.net> X-Mailer: git-send-email 2.50.0.107.gf914562f5916.dirty In-Reply-To: <20260427040517.828226-1-neilb@ownmail.net> References: <20260427040517.828226-1-neilb@ownmail.net> Reply-To: NeilBrown Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: NeilBrown Various typos fixes. start_creating_dentry() now documented as *creating*, not *removing* the entry. Unwanted spaces in Documentation/filesystems/porting.rst removed. Signed-off-by: NeilBrown --- Documentation/filesystems/porting.rst | 8 +++---- fs/namei.c | 30 +++++++++++++-------------- 2 files changed, 19 insertions(+), 19 deletions(-) diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesyst= ems/porting.rst index fdf074429cd3..bfdff4608028 100644 --- a/Documentation/filesystems/porting.rst +++ b/Documentation/filesystems/porting.rst @@ -1203,7 +1203,7 @@ will fail-safe. =20 --- =20 -** mandatory** +**mandatory** =20 lookup_one(), lookup_one_unlocked(), lookup_one_positive_unlocked() now take a qstr instead of a name and len. These, not the "one_len" @@ -1212,7 +1212,7 @@ that filesysmtem, through a mount point - which will = have a mnt_idmap. =20 --- =20 -** mandatory** +**mandatory** =20 Functions try_lookup_one_len(), lookup_one_len(), lookup_one_len_unlocked() and lookup_positive_unlocked() have been @@ -1229,7 +1229,7 @@ already been performed such as after vfs_path_parent_= lookup() =20 --- =20 -** mandatory** +**mandatory** =20 d_hash_and_lookup() is no longer exported or available outside the VFS. Use try_lookup_noperm() instead. This adds name validation and takes @@ -1371,7 +1371,7 @@ similar. =20 --- =20 -** mandatory** +**mandatory** =20 lock_rename(), lock_rename_child(), unlock_rename() are no longer available. Use start_renaming() or similar. diff --git a/fs/namei.c b/fs/namei.c index c7fac83c9a85..65e60536a6d1 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -2942,8 +2942,8 @@ struct dentry *start_dirop(struct dentry *parent, str= uct qstr *name, * end_dirop - signal completion of a dirop * @de: the dentry which was returned by start_dirop or similar. * - * If the de is an error, nothing happens. Otherwise any lock taken to - * protect the dentry is dropped and the dentry itself is release (dput()). + * If the @de is an error, nothing happens. Otherwise any lock taken to + * protect the dentry is dropped and the dentry itself is released (dput()= ). */ void end_dirop(struct dentry *de) { @@ -3260,7 +3260,7 @@ EXPORT_SYMBOL(lookup_one_unlocked); * the i_rwsem itself if necessary. If a fatal signal is pending or * delivered, it will return %-EINTR if the lock is needed. * - * Returns: A dentry, possibly negative, or + * Returns: A positive dentry, or * - same errors as lookup_one_unlocked() or * - ERR_PTR(-EINTR) if a fatal signal is pending. */ @@ -3382,7 +3382,7 @@ struct dentry *lookup_noperm_positive_unlocked(struct= qstr *name, EXPORT_SYMBOL(lookup_noperm_positive_unlocked); =20 /** - * start_creating - prepare to create a given name with permission checking + * start_creating - prepare to access or create a given name with permissi= on checking * @idmap: idmap of the mount * @parent: directory in which to prepare to create the name * @name: the name to be created @@ -3414,8 +3414,8 @@ EXPORT_SYMBOL(start_creating); * @parent: directory in which to find the name * @name: the name to be removed * - * Locks are taken and a lookup in performed prior to removing - * an object from a directory. Permission checking (MAY_EXEC) is performed + * Locks are taken and a lookup is performed prior to removing an object + * from a directory. Permission checking (MAY_EXEC) is performed * against @idmap. * * If the name doesn't exist, an error is returned. @@ -3441,7 +3441,7 @@ EXPORT_SYMBOL(start_removing); * @parent: directory in which to prepare to create the name * @name: the name to be created * - * Locks are taken and a lookup in performed prior to creating + * Locks are taken and a lookup is performed prior to creating * an object in a directory. Permission checking (MAY_EXEC) is performed * against @idmap. * @@ -3470,7 +3470,7 @@ EXPORT_SYMBOL(start_creating_killable); * @parent: directory in which to find the name * @name: the name to be removed * - * Locks are taken and a lookup in performed prior to removing + * Locks are taken and a lookup is performed prior to removing * an object from a directory. Permission checking (MAY_EXEC) is performed * against @idmap. * @@ -3500,7 +3500,7 @@ EXPORT_SYMBOL(start_removing_killable); * @parent: directory in which to prepare to create the name * @name: the name to be created * - * Locks are taken and a lookup in performed prior to creating + * Locks are taken and a lookup is performed prior to creating * an object in a directory. * * If the name already exists, a positive dentry is returned. @@ -3523,7 +3523,7 @@ EXPORT_SYMBOL(start_creating_noperm); * @parent: directory in which to find the name * @name: the name to be removed * - * Locks are taken and a lookup in performed prior to removing + * Locks are taken and a lookup is performed prior to removing * an object from a directory. * * If the name doesn't exist, an error is returned. @@ -3544,11 +3544,11 @@ struct dentry *start_removing_noperm(struct dentry = *parent, EXPORT_SYMBOL(start_removing_noperm); =20 /** - * start_creating_dentry - prepare to create a given dentry - * @parent: directory from which dentry should be removed - * @child: the dentry to be removed + * start_creating_dentry - prepare to access or create a given dentry + * @parent: directory of dentry + * @child: the dentry to be prepared * - * A lock is taken to protect the dentry again other dirops and + * A lock is taken to protect the dentry against other dirops and * the validity of the dentry is checked: correct parent and still hashed. * * If the dentry is valid and negative a reference is taken and @@ -3581,7 +3581,7 @@ EXPORT_SYMBOL(start_creating_dentry); * @parent: directory from which dentry should be removed * @child: the dentry to be removed * - * A lock is taken to protect the dentry again other dirops and + * A lock is taken to protect the dentry against other dirops and * the validity of the dentry is checked: correct parent and still hashed. * * If the dentry is valid and positive, a reference is taken and --=20 2.50.0.107.gf914562f5916.dirty From nobody Wed Jun 17 07:22:57 2026 Received: from fhigh-a5-smtp.messagingengine.com (fhigh-a5-smtp.messagingengine.com [103.168.172.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AE62B258EC1; Mon, 27 Apr 2026 04:06:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.156 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262762; cv=none; b=p6fi63xjapz3GpxaZtrSjXkptE4qTj3cBPuzZL4CRqFH8bWeiqm99d0brHETIKJpCSJdEqTA4sjAvRImvq+6TdRWOoIRNBXjGcwCsI8DeZ3NyxF3xZkbhI3ucXodee+cPAFWNY001Cy7cscVWm8iX85UB5dIZOJ+hQ/Z+UmU4IM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262762; c=relaxed/simple; bh=Pki1tNYev0WXH8WJnTY1L/60frqpJhclJSGzSK1gdE0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pPu3lvNOV4HT42ayG6PFiQADijNdmx0Hm/ugWrbynE/ngkNsvd+YbCW0HwtzeH95RZ1f6zt5gPxSTel53jJud56v09paA3A+oJsJpo/Y0aHHa6giQGzIp0Aj3uJqwOQUcN8jw1WmJn6ZWEmyGRgIWCn7etF0o62Cbm0jvywC8Wc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net; spf=pass smtp.mailfrom=ownmail.net; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b=K8nE7L4p; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=SVIXD13D; arc=none smtp.client-ip=103.168.172.156 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ownmail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b="K8nE7L4p"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="SVIXD13D" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfhigh.phl.internal (Postfix) with ESMTP id F34FF14000CC; Mon, 27 Apr 2026 00:05:59 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Mon, 27 Apr 2026 00:05:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ownmail.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to; s=fm2; t=1777262759; x=1777349159; bh=7sA1Vl5jolxK70Oa0cKHhOdpSjEUXYli5D2vNFWfhhY=; b= K8nE7L4pduA5y0M83Qf5dIrYU3gdYV+ygo3gUwi72byP8YkYRxgh+cxhM0elmonp fR5EYWE24xEs1IPBKdEKEJQAK0XvHUHpDW7Oeol654b8FNanBA0rhWjN1U8vtOg9 5N+JrS8n4c30wd4l9fFlhbz7iP9wJHeZr0sfSq0quAQygr4aw69grTJGugslwRP+ 6hUNJKLLJq5JjHVmI+7tn4GVPyiAcjZENxcffZgps02Lv3Y50XNpHR+jQDxEAc/A oCr2zwDjzMoOpWudksPLuXOM+Gp1+tToCC5YmiOBPNJ11173QU/2+SRA9NkrJlEu RTw5GXZgjVUaJsjSHVHQ2w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1777262759; x=1777349159; bh=7 sA1Vl5jolxK70Oa0cKHhOdpSjEUXYli5D2vNFWfhhY=; b=SVIXD13DUYlFT5//a ySoJ5mhnUm9g8t/6Mrkq9r/J49CaFtk+wxGMKcxcY+AslsqK8v2xCk5WA6vWxrCD eGc43vDp3e8KB72FCI8MnmZ2mNRy5YbGthgssruPQWGk3DD1tzvffnwFUWDwtayT cmsc0nKrxo515pJjRANG7ZKZcafCni0yXuxFKlaFnnBOQU7Nmji8rugdXsTWvzVh Yr3EvUpMm5xa3I4Zaq2XPtyGUMo3v3u+L/tyzpDHtEYVGKpUtMBrA/qRTp4IERp+ hz9IsBr4v3XylCJx70Dhu16QFzModvq1auvC+geM+I4FpVaLXPhkgH8d+UTRHgPp kEIPQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdejjeeijecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffkffojghfrhgggfestdekredtredttdenucfhrhhomheppfgvihhluehr ohifnhcuoehnvghilhgssehofihnmhgrihhlrdhnvghtqeenucggtffrrghtthgvrhhnpe evveekffduueevhfeigefhgfdukedtleekjeeitdejudfgueekvdekffdvfedvudenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhgsse hofihnmhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeduiedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvhhirhhoseiivghnihhvrdhlihhnuhigrdhorhhgrdhukhdprh gtphhtthhopehlihhnuhigqdhunhhiohhnfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhg pdhrtghpthhtoheplhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprh gtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehlihhnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehmihhklhhoshesshiivghrvgguihdrhhhupdhrtghpthhtohepjhgrtg hksehsuhhsvgdrtgiipdhrtghpthhtohepjhhksehoiihlrggsshdrohhrgh X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Apr 2026 00:05:55 -0400 (EDT) From: NeilBrown To: Linus Torvalds , Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Trond Myklebust , Anna Schumaker , Miklos Szeredi , Amir Goldstein , Jeremy Kerr , Ard Biesheuvel Cc: linux-efi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 02/19] VFS: enhance d_splice_alias() to handle in-lookup dentries Date: Mon, 27 Apr 2026 14:01:20 +1000 Message-ID: <20260427040517.828226-3-neilb@ownmail.net> X-Mailer: git-send-email 2.50.0.107.gf914562f5916.dirty In-Reply-To: <20260427040517.828226-1-neilb@ownmail.net> References: <20260427040517.828226-1-neilb@ownmail.net> Reply-To: NeilBrown Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: NeilBrown We currently have three interfaces for attaching existing inodes to normal filesystems(*). - d_add() requires an unhashed or in-lookup dentry and doesn't handle splicing in case a directory already has dentry - d_instantiate() requires a hashed dentry, and also doesn't handle splicing. - d_splice_alias() requires unhashed or in-lookup and does handle splicing, and can return an alternate dentry. So there is no interface that supports both hashed and in-lookup, which is what ->atomic_open needs to deal with. Some filesystems check for in-lookup in their atomic_open and if found, perform a ->lookup and can subsequently use d_instantiate() if the dentry is still negative. Others d_drop() the dentry so they can use d_splice_alias(). This last will cause a problem for proposed changes to locking which require the dentry to remain hashed while and operation proceeds on it. There is also no interface which splices a directory (which might already have a dentry) to a hashed dentry. Filesystems which need to do this d_drop() first. Some filesystemss (NFS) skip ->lookup processes for LOOKUP_CREATE|LOOKUP_EXCL which includes mknod, link, symlink etc. So these inode operations might get an unhashed or a hashed-negative dentry. There is no interface for instantiating these so against they need to unhash first. So with this patch d_splice_alias() can handle hashed, unhashed, or in-lookup dentries. This makes it suitable for ->lookup, ->atomic_open, and ->mkdir and others. As a side effect d_add() will also now handle hashed dentries, but I have plans to remove d_add() as there is no benefit having it as well as the others. __d_add() currently contains code that is identical to __d_instantiate(), so the former is changed to call the later, and both d_add() and d_instantiate() call __d_add(). * There is also d_make_persistent() for filesystems which are dcache-based and don't support mkdir, create etc, and d_instantiate_new() for newly created inodes that are still locked. Signed-off-by: NeilBrown --- Documentation/filesystems/vfs.rst | 4 ++-- fs/dcache.c | 31 ++++++++++++------------------- 2 files changed, 14 insertions(+), 21 deletions(-) diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/= vfs.rst index 7c753148af88..d8df0a84cdba 100644 --- a/Documentation/filesystems/vfs.rst +++ b/Documentation/filesystems/vfs.rst @@ -507,8 +507,8 @@ otherwise noted. dentry before the first mkdir returns. =20 If there is any chance this could happen, then the new inode - should be d_drop()ed and attached with d_splice_alias(). The - returned dentry (if any) should be returned by ->mkdir(). + should be attached with d_splice_alias(). The returned + dentry (if any) should be returned by ->mkdir(). =20 ``rmdir`` called by the rmdir(2) system call. Only required if you want diff --git a/fs/dcache.c b/fs/dcache.c index 2c61aeea41f4..789544525c56 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -2068,7 +2068,6 @@ static void __d_instantiate(struct dentry *dentry, st= ruct inode *inode) * (or otherwise set) by the caller to indicate that it is now * in use by the dcache. */ -=20 void d_instantiate(struct dentry *entry, struct inode * inode) { BUG_ON(d_really_is_positive(entry)); @@ -2822,18 +2821,14 @@ static inline void __d_add(struct dentry *dentry, s= truct inode *inode, dir =3D dentry->d_parent->d_inode; n =3D start_dir_add(dir); d_wait =3D __d_lookup_unhash(dentry); + __d_rehash(dentry); + } else if (d_unhashed(dentry)) { + __d_rehash(dentry); } if (unlikely(ops)) d_set_d_op(dentry, ops); - if (inode) { - unsigned add_flags =3D d_flags_for_inode(inode); - hlist_add_head(&dentry->d_alias, &inode->i_dentry); - raw_write_seqcount_begin(&dentry->d_seq); - __d_set_inode_and_type(dentry, inode, add_flags); - raw_write_seqcount_end(&dentry->d_seq); - fsnotify_update_flags(dentry); - } - __d_rehash(dentry); + if (inode) + __d_instantiate(dentry, inode); if (dir) end_dir_add(dir, n, d_wait); spin_unlock(&dentry->d_lock); @@ -3133,8 +3128,6 @@ struct dentry *d_splice_alias_ops(struct inode *inode= , struct dentry *dentry, if (IS_ERR(inode)) return ERR_CAST(inode); =20 - BUG_ON(!d_unhashed(dentry)); - if (!inode) goto out; =20 @@ -3183,6 +3176,8 @@ struct dentry *d_splice_alias_ops(struct inode *inode= , struct dentry *dentry, * @inode: the inode which may have a disconnected dentry * @dentry: a negative dentry which we want to point to the inode. * + * @dentry must be negative and may be in-lookup or unhashed or hashed. + * * If inode is a directory and has an IS_ROOT alias, then d_move that in * place of the given dentry and return it, else simply d_add the inode * to the dentry and return NULL. @@ -3190,16 +3185,14 @@ struct dentry *d_splice_alias_ops(struct inode *ino= de, struct dentry *dentry, * If a non-IS_ROOT directory is found, the filesystem is corrupt, and * we should error out: directories can't have multiple aliases. * - * This is needed in the lookup routine of any filesystem that is exportab= le - * (via knfsd) so that we can build dcache paths to directories effectivel= y. + * This should be used to return the result of ->lookup() and to + * instantiate the result of ->mkdir(), is often useful for + * ->atomic_open, and may be used to instantiate other objects. * * If a dentry was found and moved, then it is returned. Otherwise NULL - * is returned. This matches the expected return value of ->lookup. + * is returned. This matches the expected return value of ->lookup and + * ->mkdir. * - * Cluster filesystems may call this function with a negative, hashed dent= ry. - * In that case, we know that the inode will be a regular file, and also t= his - * will only occur during atomic_open. So we need to check for the dentry - * being already hashed only in the final case. */ struct dentry *d_splice_alias(struct inode *inode, struct dentry *dentry) { --=20 2.50.0.107.gf914562f5916.dirty From nobody Wed Jun 17 07:22:57 2026 Received: from fhigh-a5-smtp.messagingengine.com (fhigh-a5-smtp.messagingengine.com [103.168.172.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1B1EF2749ED; Mon, 27 Apr 2026 04:06:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.156 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262770; cv=none; b=qYYxWlU/38KI3fvXR1Xp/cudjNzeQoiG2/ObXFb7+rFnHsrj9p4I9kZDltd73SHs+wOyDrD6eZFltk5Fwgj5uxT2dOqn0Qigxeyq9+8eJiFIpSsDefOu2weXinkxPrVrQAcT4VMJsHfusZVrpqt6272D7dRCRFLKUOndefT+Xbg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262770; c=relaxed/simple; bh=s/WJXqScoUb+XDmgBWVvSpncv6x4V4yZ9QvNOvxlLFo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cxInazkNbhcay6/vFLM/7xz4j5Hh/vg9Gspoxp7Ot7WU+dY4sTBc87B3sF1CFovd9rm3nnuGuN5fzZ2NH4KWLaWzOjqWURrvthWqGf593UPRg43IpnUCXNbYfaZ8mi34FfZ2DuD7pmoR2ywi0I1ZI2Eyvbe07W+NYb9a4SoYd8c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net; spf=pass smtp.mailfrom=ownmail.net; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b=VfuxPkre; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=XZXu+OZa; arc=none smtp.client-ip=103.168.172.156 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ownmail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b="VfuxPkre"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="XZXu+OZa" Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.phl.internal (Postfix) with ESMTP id 4B3161400018; Mon, 27 Apr 2026 00:06:08 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Mon, 27 Apr 2026 00:06:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ownmail.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to; s=fm2; t=1777262768; x=1777349168; bh=g8SM3Dg2naVtDlBlkJGj5seH51i8ZJRCDyDc8L3ShjQ=; b= VfuxPkre9XHX3HlrcmM02xx1B1pWS7FixmGdHSgOnlmTKlgMaUFz7oCkcmQdXwZE 0ePQuwhcekwpXYrYOalE0feLIeFxS56XwNst6r6GqjAz1jVyIgMb09+5wOVGR/GM oT68SN34xT2u4ea9s3EzES5pfdiuqRUXvK5woV7wG3hHFTVurRC7YTivW5HiAGlZ JoWxKpdLgwVfsXJhGQITP1/jCKM3Zg0TNiBDIO+2m3g8kp3BTxi0tWPAI7xam9ie Quwk/SgSGdk673hfuJYNFZljTmtilxXQ0zEn7T+0B1yZcuERSAbRDH9gsMiJAMvZ rmonSvgzudKO8JOAr4MjQw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1777262768; x=1777349168; bh=g 8SM3Dg2naVtDlBlkJGj5seH51i8ZJRCDyDc8L3ShjQ=; b=XZXu+OZaBidJ+mBjB VCIKrKF8S1v5z8o2qv+iQjCY7GlrD+Ys3ePlu+wUqcSVpigv1Ng++/S+tk3aE/j4 2/zZCUnP08HAfgtGXhlBP/zDfQDbnVxuPq92M9zvxFndU1WCU3UL0Pk5bhphKgks RF/PK3H5FMefyAVvLCNw0vgdtKYlmdyrEXzWXzsyF+cMT/QE1PjrtzIZ3J8ktqAe hC2I1cIieNgMEXWSO2VuKykdVaQB8YyN6daq8fqXm8C44Ex4EK1IewPSfG98HZnl fa3spEE4B9Lx3Biw8u4aKiN0RG/Jx4sfVUFV5UqF2P020KBemlvAWegt+M+fgDlv z9gng== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdejjeeikecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffkffojghfrhgggfestdekredtredttdenucfhrhhomheppfgvihhluehr ohifnhcuoehnvghilhgssehofihnmhgrihhlrdhnvghtqeenucggtffrrghtthgvrhhnpe evveekffduueevhfeigefhgfdukedtleekjeeitdejudfgueekvdekffdvfedvudenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhgsse hofihnmhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeduiedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvhhirhhoseiivghnihhvrdhlihhnuhigrdhorhhgrdhukhdprh gtphhtthhopehlihhnuhigqdhunhhiohhnfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhg pdhrtghpthhtoheplhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprh gtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehlihhnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehmihhklhhoshesshiivghrvgguihdrhhhupdhrtghpthhtohepjhgrtg hksehsuhhsvgdrtgiipdhrtghpthhtohepjhhksehoiihlrggsshdrohhrgh X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Apr 2026 00:06:03 -0400 (EDT) From: NeilBrown To: Linus Torvalds , Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Trond Myklebust , Anna Schumaker , Miklos Szeredi , Amir Goldstein , Jeremy Kerr , Ard Biesheuvel Cc: linux-efi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 03/19] VFS: allow d_alloc_name() to be used with ->d_hash Date: Mon, 27 Apr 2026 14:01:21 +1000 Message-ID: <20260427040517.828226-4-neilb@ownmail.net> X-Mailer: git-send-email 2.50.0.107.gf914562f5916.dirty In-Reply-To: <20260427040517.828226-1-neilb@ownmail.net> References: <20260427040517.828226-1-neilb@ownmail.net> Reply-To: NeilBrown Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: NeilBrown efivarfs() is similar to other filesystems which use d_alloc_name(), but it cannot use d_alloc_name() as it has a ->d_hash function. The only problem with using ->d_hash if available is that it can return an error, but d_alloc_name() cannot. If we document that d_alloc_name() cannot be used when ->d_hash returns an error, then any filesystem which has a safe ->d_hash can safely use d_alloc_name(). So enhance d_alloc_name() to check for a ->d_hash function and document that this is not permitted if the ->d_hash function can fail( which efivarfs_d_hash() cannot). Also document locking requirements for use. This is a step towards eventually deprecating d_alloc(). Signed-off-by: NeilBrown --- fs/dcache.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/fs/dcache.c b/fs/dcache.c index 789544525c56..d0a504fc62e5 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -1945,12 +1945,31 @@ struct dentry *d_alloc_pseudo(struct super_block *s= b, const struct qstr *name) return dentry; } =20 +/** + * d_alloc_name: allocate a dentry for use in a dcache-based filesystem. + * @parent: dentry of the parent for the dentry + * @name: name of the dentry + * + * d_alloc_name() allocates a dentry without any protection against + * races. It should only be used in directories that do not support + * create/rename/link inode operations and so is particularly suited for + * use with simple_dir_inode_operations. The result is typically passed + * to d_make_persistent(). + * + * This must NOT be used by filesystems which provide a d_hash() function + * that can return an error. + */ struct dentry *d_alloc_name(struct dentry *parent, const char *name) { struct qstr q; =20 q.name =3D name; q.hash_len =3D hashlen_string(parent, name); + if (parent->d_flags & DCACHE_OP_HASH) { + int err =3D parent->d_op->d_hash(parent, &q); + if (WARN_ON_ONCE(err)) + return NULL; + } return d_alloc(parent, &q); } EXPORT_SYMBOL(d_alloc_name); --=20 2.50.0.107.gf914562f5916.dirty From nobody Wed Jun 17 07:22:57 2026 Received: from fhigh-a5-smtp.messagingengine.com (fhigh-a5-smtp.messagingengine.com [103.168.172.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 685F7258EC1; Mon, 27 Apr 2026 04:06:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.156 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262778; cv=none; b=kGm8GYV9Mx4bV2/Az4Bgz0oqOEaHDSOfi2bH3SRcWXnVS6Bv3ZmzUurHDI4iHSFLBGskGcZ3wgSkkO9i2j8g0KaFUQ53hW0O1ZPGCwtZfJkac9EgXkj54Wv2OPKmFj48USJ07OPb3HKdI+Q1yrHNliNqXitSUDTyotcjyZojeUU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262778; c=relaxed/simple; bh=CfKT9Gn4c1XhDbo0WloY/nniuKRLh4xGe4NRIk+ECX0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jyoU9uI303Xe5weBy8fMtJOGENdFp6aImhzQAMnGvn3yUmXFKTTeWV/ngGoiCrFgJXYkNVh67HpN5w/QfgMUyDdrosJlK5dPvT0W60x7p8TaRjDawbOGzgJ+rij3Em9iEQlI7RqsJdQTY0vG0okW8H9ZDqc5NlTDon20KQspAhw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net; spf=pass smtp.mailfrom=ownmail.net; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b=aGgp10yP; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=tK5vndnm; arc=none smtp.client-ip=103.168.172.156 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ownmail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b="aGgp10yP"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="tK5vndnm" Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfhigh.phl.internal (Postfix) with ESMTP id BACB51400018; Mon, 27 Apr 2026 00:06:15 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Mon, 27 Apr 2026 00:06:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ownmail.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to; s=fm2; t=1777262775; x=1777349175; bh=M+q69xEVOxYDlLesgsc7OKN8RwYSBXfFhfRK/I9my0w=; b= aGgp10yP76Wkf65zuOzOBpCLDu7ydSxEm6packZGwr2eZgcjA+YNLQTDg1Bpuh7K 9QLCvpRf4UK+ALH8wcetH1QeoBwfJHmoAOzoW7tEcRRxCd1P41RlFLt3fH/6wega ajznoda773+jYmR+ddmn+B+fm0gSX11GRSVtt3uuy7r5cZSpRiDuET3SHtx+pRaP TPslxDaoKja6csPL8cMjzPXdidBx/kDR+tsuq2VVQBlByIkbhRmHhvqZHGwZKPz0 XyXJnmkzDPcNv5MN6C+/abt8BSBk9m2ailHozh0FinGWsBABGQU4eST80gmTvAgl KTMTnhXGDmy3XaOKRd2FzA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1777262775; x=1777349175; bh=M +q69xEVOxYDlLesgsc7OKN8RwYSBXfFhfRK/I9my0w=; b=tK5vndnmd6XjEVb0P yxt70x/JVJyWWTPpYoQVz+Ixbd0RHQOgcb/WI58dJvaUlJH/B3lGDZ8RPVYRKtMf KES6l4AgU7thYnnr/tPEFjBbLYvq9DrfAMrg8GsSPUG9LwlxmOcbz6ivB7iLKt1t e8z/QSSuiTRnEU+0yN5Lwvu4qy9HQtOsIAcTYsS2kqPdjw4rCokoVec6Q47hD//P rUJXgAAzvGITD+YsieXWjJoxaooZLjE4brOd/epNxBfWxo2ZVLYurO+z2kTJ2jsm oBCyjjMs+yGgMsp1tbHekEWzX2RhIXtnNlWwvsUYdnYdAejJU7WhgUUSLP6TBuKz ARvlw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdejjeeikecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffkffojghfrhgggfestdekredtredttdenucfhrhhomheppfgvihhluehr ohifnhcuoehnvghilhgssehofihnmhgrihhlrdhnvghtqeenucggtffrrghtthgvrhhnpe evveekffduueevhfeigefhgfdukedtleekjeeitdejudfgueekvdekffdvfedvudenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhgsse hofihnmhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeduiedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvhhirhhoseiivghnihhvrdhlihhnuhigrdhorhhgrdhukhdprh gtphhtthhopehlihhnuhigqdhunhhiohhnfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhg pdhrtghpthhtoheplhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprh gtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehlihhnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehmihhklhhoshesshiivghrvgguihdrhhhupdhrtghpthhtohepjhgrtg hksehsuhhsvgdrtgiipdhrtghpthhtohepjhhksehoiihlrggsshdrohhrgh X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Apr 2026 00:06:10 -0400 (EDT) From: NeilBrown To: Linus Torvalds , Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Trond Myklebust , Anna Schumaker , Miklos Szeredi , Amir Goldstein , Jeremy Kerr , Ard Biesheuvel Cc: linux-efi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 04/19] VFS: use wait_var_event for waiting in d_alloc_parallel() Date: Mon, 27 Apr 2026 14:01:22 +1000 Message-ID: <20260427040517.828226-5-neilb@ownmail.net> X-Mailer: git-send-email 2.50.0.107.gf914562f5916.dirty In-Reply-To: <20260427040517.828226-1-neilb@ownmail.net> References: <20260427040517.828226-1-neilb@ownmail.net> Reply-To: NeilBrown Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: NeilBrown d_alloc_parallel() currently requires a wait_queue_head to be passed in. This must have a life time which extends until the lookup is completed. This makes it awkward to use and particularly make it hard to use in lookup_one_qstr_excl() which I hope to do in the future. This patch changes d_alloc_parallel() to use wake_up_var_locked() to wake up waiters, and wait_var_event_spinlock() to wait. dentry->d_lock is used for synchronisation as it is already held and the relevant times. In most cases there will be no waiters so the wake_up_var_locked() call is a complete waste. To optimise this a new ->d_flags flag is added: DCACHE_LOCK_WAITERS. This is set whenever any thread prepares to wait for the dentry, and if it isn't set when DCACHE_PAR_LOOKUP is cleared, no wakeup is sent. (The name is deliberately generic as I plan to replace DCACHE_PAR_LOOKUP with more generic per-dentry locking in the future). __d_lookup_unhash() now returns a bool rather than a wq. This is true if DCACHE_LOCK_WAITERS was sent and is used to decide to send the wake up. It would be easier to send the wakeup immediately when clearing DCACHE_LOCK_WAITERS, but then the waiter could wake a bit earlier and then spend time spinning on ->d_lock. I don't know if that cost is interesting. __d_lookup_unhash() no longer needs to re-init ->d_lru. That was previously shared (in a union) with ->d_wait but ->d_wait is now gone so it no longer corrupts ->d_lru. Signed-off-by: NeilBrown --- Documentation/filesystems/porting.rst | 7 +++ fs/afs/dir_silly.c | 4 +- fs/dcache.c | 64 ++++++++++++--------------- fs/fuse/readdir.c | 3 +- fs/namei.c | 6 +-- fs/nfs/dir.c | 6 +-- fs/nfs/unlink.c | 3 +- fs/proc/base.c | 3 +- fs/proc/proc_sysctl.c | 3 +- fs/smb/client/readdir.c | 3 +- include/linux/dcache.h | 11 +++-- include/linux/nfs_xdr.h | 1 - 12 files changed, 51 insertions(+), 63 deletions(-) diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesyst= ems/porting.rst index bfdff4608028..85c7b2007f8c 100644 --- a/Documentation/filesystems/porting.rst +++ b/Documentation/filesystems/porting.rst @@ -1385,3 +1385,10 @@ for_each_alias(dentry, inode) instead of hlist_for_e= ach_entry; better yet, see if any of the exported primitives could be used instead of the entire loop. You still need to hold ->i_lock of the inode over either form of manual loop. + +--- + +**mandatory** + +d_alloc_parallel() no longer requires a waitqueue_head. + diff --git a/fs/afs/dir_silly.c b/fs/afs/dir_silly.c index a748fd133faf..982bb6ec15f0 100644 --- a/fs/afs/dir_silly.c +++ b/fs/afs/dir_silly.c @@ -248,13 +248,11 @@ int afs_silly_iput(struct dentry *dentry, struct inod= e *inode) struct dentry *alias; int ret; =20 - DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq); - _enter("%p{%pd},%llx", dentry, dentry, vnode->fid.vnode); =20 down_read(&dvnode->rmdir_lock); =20 - alias =3D d_alloc_parallel(dentry->d_parent, &dentry->d_name, &wq); + alias =3D d_alloc_parallel(dentry->d_parent, &dentry->d_name); if (IS_ERR(alias)) { up_read(&dvnode->rmdir_lock); return 0; diff --git a/fs/dcache.c b/fs/dcache.c index d0a504fc62e5..2dcefa60db32 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -2268,8 +2268,7 @@ struct dentry *d_add_ci(struct dentry *dentry, struct= inode *inode, return found; } if (d_in_lookup(dentry)) { - found =3D d_alloc_parallel(dentry->d_parent, name, - dentry->d_wait); + found =3D d_alloc_parallel(dentry->d_parent, name); if (IS_ERR(found) || !d_in_lookup(found)) { iput(inode); return found; @@ -2279,7 +2278,7 @@ struct dentry *d_add_ci(struct dentry *dentry, struct= inode *inode, if (!found) { iput(inode); return ERR_PTR(-ENOMEM); - }=20 + } } res =3D d_splice_alias(inode, found); if (res) { @@ -2657,31 +2656,24 @@ static inline unsigned start_dir_add(struct inode *= dir) } =20 static inline void end_dir_add(struct inode *dir, unsigned int n, - wait_queue_head_t *d_wait) + bool do_wake, struct dentry *de) { smp_store_release(&dir->i_dir_seq, n + 2); preempt_enable_nested(); - if (wq_has_sleeper(d_wait)) - wake_up_all(d_wait); + if (do_wake) + wake_up_var_locked(&de->d_flags, &de->d_lock); } =20 -static void d_wait_lookup(struct dentry *dentry) +static inline bool d_must_wait(struct dentry *dentry) { - if (d_in_lookup(dentry)) { - DECLARE_WAITQUEUE(wait, current); - add_wait_queue(dentry->d_wait, &wait); - do { - set_current_state(TASK_UNINTERRUPTIBLE); - spin_unlock(&dentry->d_lock); - schedule(); - spin_lock(&dentry->d_lock); - } while (d_in_lookup(dentry)); - } + if (!d_in_lookup(dentry)) + return false; + dentry->d_flags |=3D DCACHE_LOCK_WAITER; + return true; } =20 struct dentry *d_alloc_parallel(struct dentry *parent, - const struct qstr *name, - wait_queue_head_t *wq) + const struct qstr *name) { unsigned int hash =3D name->hash; struct hlist_bl_head *b =3D in_lookup_hash(parent, hash); @@ -2763,7 +2755,9 @@ struct dentry *d_alloc_parallel(struct dentry *parent, * wait for them to finish */ spin_lock(&dentry->d_lock); - d_wait_lookup(dentry); + wait_var_event_spinlock(&dentry->d_flags, + !d_must_wait(dentry), + &dentry->d_lock); /* * it's not in-lookup anymore; in principle we should repeat * everything from dcache lookup, but it's likely to be what @@ -2784,7 +2778,6 @@ struct dentry *d_alloc_parallel(struct dentry *parent, return dentry; } rcu_read_unlock(); - new->d_wait =3D wq; hlist_bl_add_head(&new->d_in_lookup_hash, b); hlist_bl_unlock(b); return new; @@ -2800,29 +2793,29 @@ EXPORT_SYMBOL(d_alloc_parallel); * - Retrieve and clear the waitqueue head in dentry * - Return the waitqueue head */ -static wait_queue_head_t *__d_lookup_unhash(struct dentry *dentry) +static bool __d_lookup_unhash(struct dentry *dentry) { - wait_queue_head_t *d_wait; struct hlist_bl_head *b; + bool do_wake; =20 lockdep_assert_held(&dentry->d_lock); =20 b =3D in_lookup_hash(dentry->d_parent, dentry->d_name.hash); hlist_bl_lock(b); - dentry->d_flags &=3D ~DCACHE_PAR_LOOKUP; __hlist_bl_del(&dentry->d_in_lookup_hash); - d_wait =3D dentry->d_wait; - dentry->d_wait =3D NULL; + do_wake =3D !!(dentry->d_flags & DCACHE_LOCK_WAITER); + dentry->d_flags &=3D ~(DCACHE_PAR_LOOKUP|DCACHE_LOCK_WAITER); + hlist_bl_unlock(b); dentry->waiters =3D NULL; - INIT_LIST_HEAD(&dentry->d_lru); - return d_wait; + return do_wake; } =20 void __d_lookup_unhash_wake(struct dentry *dentry) { spin_lock(&dentry->d_lock); - wake_up_all(__d_lookup_unhash(dentry)); + if (__d_lookup_unhash(dentry)) + wake_up_var_locked(&dentry->d_flags, &dentry->d_lock); spin_unlock(&dentry->d_lock); } EXPORT_SYMBOL(__d_lookup_unhash_wake); @@ -2832,14 +2825,15 @@ EXPORT_SYMBOL(__d_lookup_unhash_wake); static inline void __d_add(struct dentry *dentry, struct inode *inode, const struct dentry_operations *ops) { - wait_queue_head_t *d_wait; + bool do_wake =3D false; struct inode *dir =3D NULL; unsigned n; + spin_lock(&dentry->d_lock); if (unlikely(d_in_lookup(dentry))) { dir =3D dentry->d_parent->d_inode; n =3D start_dir_add(dir); - d_wait =3D __d_lookup_unhash(dentry); + do_wake =3D __d_lookup_unhash(dentry); __d_rehash(dentry); } else if (d_unhashed(dentry)) { __d_rehash(dentry); @@ -2849,7 +2843,7 @@ static inline void __d_add(struct dentry *dentry, str= uct inode *inode, if (inode) __d_instantiate(dentry, inode); if (dir) - end_dir_add(dir, n, d_wait); + end_dir_add(dir, n, do_wake, dentry); spin_unlock(&dentry->d_lock); if (inode) spin_unlock(&inode->i_lock); @@ -2962,7 +2956,7 @@ static void __d_move(struct dentry *dentry, struct de= ntry *target, bool exchange) { struct dentry *old_parent, *p; - wait_queue_head_t *d_wait; + bool do_wake =3D false; struct inode *dir =3D NULL; unsigned n; =20 @@ -2993,7 +2987,7 @@ static void __d_move(struct dentry *dentry, struct de= ntry *target, if (unlikely(d_in_lookup(target))) { dir =3D target->d_parent->d_inode; n =3D start_dir_add(dir); - d_wait =3D __d_lookup_unhash(target); + do_wake =3D __d_lookup_unhash(target); } =20 write_seqcount_begin(&dentry->d_seq); @@ -3033,7 +3027,7 @@ static void __d_move(struct dentry *dentry, struct de= ntry *target, write_seqcount_end(&dentry->d_seq); =20 if (dir) - end_dir_add(dir, n, d_wait); + end_dir_add(dir, n, do_wake, target); =20 if (dentry->d_parent !=3D old_parent) spin_unlock(&dentry->d_parent->d_lock); diff --git a/fs/fuse/readdir.c b/fs/fuse/readdir.c index db5ae8ec1030..a2361f1d9905 100644 --- a/fs/fuse/readdir.c +++ b/fs/fuse/readdir.c @@ -164,7 +164,6 @@ static int fuse_direntplus_link(struct file *file, struct inode *dir =3D d_inode(parent); struct fuse_conn *fc; struct inode *inode; - DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq); int epoch; =20 if (!o->nodeid) { @@ -201,7 +200,7 @@ static int fuse_direntplus_link(struct file *file, dentry =3D d_lookup(parent, &name); if (!dentry) { retry: - dentry =3D d_alloc_parallel(parent, &name, &wq); + dentry =3D d_alloc_parallel(parent, &name); if (IS_ERR(dentry)) return PTR_ERR(dentry); } diff --git a/fs/namei.c b/fs/namei.c index 65e60536a6d1..a6349b31fdb6 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -1891,13 +1891,12 @@ static struct dentry *__lookup_slow(const struct qs= tr *name, { struct dentry *dentry, *old; struct inode *inode =3D dir->d_inode; - DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq); =20 /* Don't go there if it's already dead */ if (unlikely(IS_DEADDIR(inode))) return ERR_PTR(-ENOENT); again: - dentry =3D d_alloc_parallel(dir, name, &wq); + dentry =3D d_alloc_parallel(dir, name); if (IS_ERR(dentry)) return dentry; if (unlikely(!d_in_lookup(dentry))) { @@ -4414,7 +4413,6 @@ static struct dentry *lookup_open(struct nameidata *n= d, struct file *file, struct dentry *dentry; int error, create_error =3D 0; umode_t mode =3D op->mode; - DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq); =20 if (unlikely(IS_DEADDIR(dir_inode))) return ERR_PTR(-ENOENT); @@ -4423,7 +4421,7 @@ static struct dentry *lookup_open(struct nameidata *n= d, struct file *file, dentry =3D d_lookup(dir, &nd->last); for (;;) { if (!dentry) { - dentry =3D d_alloc_parallel(dir, &nd->last, &wq); + dentry =3D d_alloc_parallel(dir, &nd->last); if (IS_ERR(dentry)) return dentry; } diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c index e9ce1883288c..9580af999d70 100644 --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -726,7 +726,6 @@ void nfs_prime_dcache(struct dentry *parent, struct nfs= _entry *entry, unsigned long dir_verifier) { struct qstr filename =3D QSTR_INIT(entry->name, entry->len); - DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq); struct dentry *dentry; struct dentry *alias; struct inode *inode; @@ -755,7 +754,7 @@ void nfs_prime_dcache(struct dentry *parent, struct nfs= _entry *entry, dentry =3D d_lookup(parent, &filename); again: if (!dentry) { - dentry =3D d_alloc_parallel(parent, &filename, &wq); + dentry =3D d_alloc_parallel(parent, &filename); if (IS_ERR(dentry)) return; } @@ -2106,7 +2105,6 @@ int nfs_atomic_open(struct inode *dir, struct dentry = *dentry, struct file *file, unsigned open_flags, umode_t mode) { - DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq); struct nfs_open_context *ctx; struct dentry *res; struct iattr attr =3D { .ia_valid =3D ATTR_OPEN }; @@ -2162,7 +2160,7 @@ int nfs_atomic_open(struct inode *dir, struct dentry = *dentry, d_drop(dentry); switched =3D true; dentry =3D d_alloc_parallel(dentry->d_parent, - &dentry->d_name, &wq); + &dentry->d_name); if (IS_ERR(dentry)) return PTR_ERR(dentry); if (unlikely(!d_in_lookup(dentry))) diff --git a/fs/nfs/unlink.c b/fs/nfs/unlink.c index df3ca4669df6..43ea897943c0 100644 --- a/fs/nfs/unlink.c +++ b/fs/nfs/unlink.c @@ -124,7 +124,7 @@ static int nfs_call_unlink(struct dentry *dentry, struc= t inode *inode, struct nf struct dentry *alias; =20 down_read_non_owner(&NFS_I(dir)->rmdir_sem); - alias =3D d_alloc_parallel(dentry->d_parent, &data->args.name, &data->wq); + alias =3D d_alloc_parallel(dentry->d_parent, &data->args.name); if (IS_ERR(alias)) { up_read_non_owner(&NFS_I(dir)->rmdir_sem); return 0; @@ -185,7 +185,6 @@ nfs_async_unlink(struct dentry *dentry, const struct qs= tr *name) =20 data->cred =3D get_current_cred(); data->res.dir_attr =3D &data->dir_attr; - init_waitqueue_head(&data->wq); =20 status =3D -EBUSY; spin_lock(&dentry->d_lock); diff --git a/fs/proc/base.c b/fs/proc/base.c index d9acfa89c894..d55a4b603188 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -2132,8 +2132,7 @@ bool proc_fill_cache(struct file *file, struct dir_co= ntext *ctx, goto end_instantiate; =20 if (!child) { - DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq); - child =3D d_alloc_parallel(dir, &qname, &wq); + child =3D d_alloc_parallel(dir, &qname); if (IS_ERR(child)) goto end_instantiate; if (d_in_lookup(child)) { diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c index 49ab74e0bfde..04a382178c65 100644 --- a/fs/proc/proc_sysctl.c +++ b/fs/proc/proc_sysctl.c @@ -692,8 +692,7 @@ static bool proc_sys_fill_cache(struct file *file, =20 child =3D d_lookup(dir, &qname); if (!child) { - DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq); - child =3D d_alloc_parallel(dir, &qname, &wq); + child =3D d_alloc_parallel(dir, &qname); if (IS_ERR(child)) return false; if (d_in_lookup(child)) { diff --git a/fs/smb/client/readdir.c b/fs/smb/client/readdir.c index be22bbc4a65a..a8995261831c 100644 --- a/fs/smb/client/readdir.c +++ b/fs/smb/client/readdir.c @@ -73,7 +73,6 @@ cifs_prime_dcache(struct dentry *parent, struct qstr *nam= e, struct cifs_sb_info *cifs_sb =3D CIFS_SB(sb); bool posix =3D cifs_sb_master_tcon(cifs_sb)->posix_extensions; bool reparse_need_reval =3D false; - DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq); int rc; =20 cifs_dbg(FYI, "%s: for %s\n", __func__, name->name); @@ -105,7 +104,7 @@ cifs_prime_dcache(struct dentry *parent, struct qstr *n= ame, (fattr->cf_flags & CIFS_FATTR_NEED_REVAL)) return; =20 - dentry =3D d_alloc_parallel(parent, name, &wq); + dentry =3D d_alloc_parallel(parent, name); } if (IS_ERR(dentry)) return; diff --git a/include/linux/dcache.h b/include/linux/dcache.h index 2577c05f84ec..14b91a7d0bb6 100644 --- a/include/linux/dcache.h +++ b/include/linux/dcache.h @@ -116,10 +116,7 @@ struct dentry { * possible! */ =20 - union { - struct list_head d_lru; /* LRU list */ - wait_queue_head_t *d_wait; /* in-lookup ones only */ - }; + struct list_head d_lru; /* LRU list */ struct hlist_node d_sib; /* child of parent list */ struct hlist_head d_children; /* our children */ /* @@ -210,6 +207,9 @@ enum dentry_flags { DCACHE_REFERENCED =3D BIT(6), /* Recently used, don't discard. */ DCACHE_DONTCACHE =3D BIT(7), /* Purge from memory on final dput() */ DCACHE_CANT_MOUNT =3D BIT(8), + DCACHE_LOCK_WAITER =3D BIT(9), /* A thread is waiting for + * PAR_LOOKUP to clear + */ DCACHE_SHRINK_LIST =3D BIT(10), DCACHE_OP_WEAK_REVALIDATE =3D BIT(11), /* @@ -256,8 +256,7 @@ extern void d_delete(struct dentry *); /* allocate/de-allocate */ extern struct dentry * d_alloc(struct dentry *, const struct qstr *); extern struct dentry * d_alloc_anon(struct super_block *); -extern struct dentry * d_alloc_parallel(struct dentry *, const struct qstr= *, - wait_queue_head_t *); +extern struct dentry * d_alloc_parallel(struct dentry *, const struct qstr= *); extern struct dentry * d_splice_alias(struct inode *, struct dentry *); /* weird procfs mess; *NOT* exported */ extern struct dentry * d_splice_alias_ops(struct inode *, struct dentry *, diff --git a/include/linux/nfs_xdr.h b/include/linux/nfs_xdr.h index fcbd21b5685f..6aced49d5f00 100644 --- a/include/linux/nfs_xdr.h +++ b/include/linux/nfs_xdr.h @@ -1743,7 +1743,6 @@ struct nfs_unlinkdata { struct nfs_removeargs args; struct nfs_removeres res; struct dentry *dentry; - wait_queue_head_t wq; const struct cred *cred; struct nfs_fattr dir_attr; long timeout; --=20 2.50.0.107.gf914562f5916.dirty From nobody Wed Jun 17 07:22:57 2026 Received: from fhigh-a5-smtp.messagingengine.com (fhigh-a5-smtp.messagingengine.com [103.168.172.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 59721258EC1; Mon, 27 Apr 2026 04:06:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.156 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262786; cv=none; b=HgDIOKdgVQ+2ZB+RhHe2h8zhGx4G3hyIq+jijbDRkWCTKGGSC/g8eP5Tv2aaLazms5/4uKMOHrXN6/MfYHslKsr+ejdprJ7qKgWohlyPQMdkG/mJlwtunmCarqf8rX8RCxl0ouFqaLVXkH2XIy6/+Cm61WTjn24S5fjtEMcjqZg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262786; c=relaxed/simple; bh=7PSFy+u24kcVfO16woP75mAbbdGt9GZMtu9sxyLPjrI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LC1iAymbYLzLce52a7IfzYLnOVEtlYjSw/QZa655/y2w7n3qHEYuxw2ePqnhROEwmSm167USCxerQ/FJmgx37erZ9veFlPR7qiRvlQ4E7AgMZge4n7D9iIccqtpBF98RBLcdr7XzCRkffI1OojNbwbXDp2tCY6NgxcXdOwL10Qo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net; spf=pass smtp.mailfrom=ownmail.net; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b=holsSESn; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=i897OZXF; arc=none smtp.client-ip=103.168.172.156 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ownmail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b="holsSESn"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="i897OZXF" Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.phl.internal (Postfix) with ESMTP id 9ECC51400046; Mon, 27 Apr 2026 00:06:24 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Mon, 27 Apr 2026 00:06:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ownmail.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to; s=fm2; t=1777262784; x=1777349184; bh=8lHsylfevHWLXpDXjo+WYhNqHlp+1vh5/Px2rcHI56c=; b= holsSESn4c1BE330f4Gqjb9IFnJNYkTUtusbN5lqK0XjlsA8rpQB6JrRxuE1+U6Z 6pj8CbsWgK9pZJw6Roqd82KMqcccUk13AVwB6JC5DX7MrNAFj6M1+bYHZf7eS5QN XmUy3AT3lSnOZpzaba20jHHRFwl9cI/ytqxqyIG0ctNiKBtKw0FFVxQGqQMGo6b3 DXspIOqgG7fJca5JdgF9C+gmuoYo7GdOJdBFSOvYQ8QnyWhKUMMj95Srywwd2hUU u1xh30tCNoZq7/CRLmL6xgyGL8QIWxamo+HZuHSCRnYa7HajbWoFUhFhcSZ/Lddo h966wKmbX5VgNhNiOuXFeg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1777262784; x=1777349184; bh=8 lHsylfevHWLXpDXjo+WYhNqHlp+1vh5/Px2rcHI56c=; b=i897OZXFm+CR1E6WF 0wQ7Uz54x1zIVJYG/EN9eD/HvKh9RUJS3JxUw2f1UT1pQqMv9+/f7BpEniTWwKkS 8J7zBnFG7l6Y9kKQ7fv0OkYYmqHamy/T8BeYTBkA7bqns4XyZs4uXbrX9Ufv1Hur fjXHkfKguUTbHLm74BUunf1qqNwzNMsuDVizdhYec+LbSRN//alecTBUy0hlMUjQ tsHAVzhE64J6bLV0VW+m1os2HQi8abjh9KN4/OieCkEaAi3LPd4YdBBmZrWhPSw6 ixYigmuQZzQK0lLXEXnTuW1WQg+LzRMamys6iroQNJ3kfNilZBNh5xR/LGT+Yk78 WgT8w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdejjeeikecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffkffojghfrhgggfestdekredtredttdenucfhrhhomheppfgvihhluehr ohifnhcuoehnvghilhgssehofihnmhgrihhlrdhnvghtqeenucggtffrrghtthgvrhhnpe evveekffduueevhfeigefhgfdukedtleekjeeitdejudfgueekvdekffdvfedvudenucev lhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhgsse hofihnmhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeduiedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvhhirhhoseiivghnihhvrdhlihhnuhigrdhorhhgrdhukhdprh gtphhtthhopehlihhnuhigqdhunhhiohhnfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhg pdhrtghpthhtoheplhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprh gtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehlihhnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehmihhklhhoshesshiivghrvgguihdrhhhupdhrtghpthhtohepjhgrtg hksehsuhhsvgdrtgiipdhrtghpthhtohepjhhksehoiihlrggsshdrohhrgh X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Apr 2026 00:06:20 -0400 (EDT) From: NeilBrown To: Linus Torvalds , Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Trond Myklebust , Anna Schumaker , Miklos Szeredi , Amir Goldstein , Jeremy Kerr , Ard Biesheuvel Cc: linux-efi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 05/19] VFS: introduce d_alloc_noblock() Date: Mon, 27 Apr 2026 14:01:23 +1000 Message-ID: <20260427040517.828226-6-neilb@ownmail.net> X-Mailer: git-send-email 2.50.0.107.gf914562f5916.dirty In-Reply-To: <20260427040517.828226-1-neilb@ownmail.net> References: <20260427040517.828226-1-neilb@ownmail.net> Reply-To: NeilBrown Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: NeilBrown Several filesystems use the results of readdir to prime the dcache. These filesystems use d_alloc_parallel() which can block if there is a concurrent lookup. Blocking in that case is pointless as the lookup will add info to the dcache and there is no value in the readdir waiting to see if it should add the info too. Also these calls to d_alloc_parallel() are made while the parent directory is locked. A proposed change to locking will lock the parent later, after d_alloc_parallel(). This means it won't be safe to wait in d_alloc_parallel() while holding the directory lock. So this patch introduces d_alloc_noblock() which doesn't block but instead returns ERR_PTR(-EWOULDBLOCK). Filesystems that prime the dcache (smb/client, nfs, fuse, cephfs) can now use that and ignore -EWOULDBLOCK errors as harmless. Unlike d_alloc_parallel(), d_alloc_noblock() calculates the hash and performs a lookup before an allocation, as that is what all callers want. Signed-off-by: NeilBrown --- fs/dcache.c | 91 +++++++++++++++++++++++++++++++++++++++--- include/linux/dcache.h | 1 + 2 files changed, 87 insertions(+), 5 deletions(-) diff --git a/fs/dcache.c b/fs/dcache.c index 2dcefa60db32..dc06e70695d2 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -32,6 +32,7 @@ #include #include #include +#include #include "internal.h" #include "mount.h" =20 @@ -2672,8 +2673,16 @@ static inline bool d_must_wait(struct dentry *dentry) return true; } =20 -struct dentry *d_alloc_parallel(struct dentry *parent, - const struct qstr *name) +/* What to do when __d_alloc_parallel finds a d_in_lookup dentry */ +enum alloc_para { + ALLOC_PARA_WAIT, + ALLOC_PARA_FAIL, +}; + +static inline +struct dentry *__d_alloc_parallel(struct dentry *parent, + const struct qstr *name, + enum alloc_para how) { unsigned int hash =3D name->hash; struct hlist_bl_head *b =3D in_lookup_hash(parent, hash); @@ -2755,9 +2764,20 @@ struct dentry *d_alloc_parallel(struct dentry *paren= t, * wait for them to finish */ spin_lock(&dentry->d_lock); - wait_var_event_spinlock(&dentry->d_flags, - !d_must_wait(dentry), - &dentry->d_lock); + if (d_in_lookup(dentry)) + switch (how) { + case ALLOC_PARA_FAIL: + spin_unlock(&dentry->d_lock); + dput(new); + dput(dentry); + return ERR_PTR(-EWOULDBLOCK); + case ALLOC_PARA_WAIT: + wait_var_event_spinlock(&dentry->d_flags, + !d_must_wait(dentry), + &dentry->d_lock); + /* ... and continue */ + } + /* * it's not in-lookup anymore; in principle we should repeat * everything from dcache lookup, but it's likely to be what @@ -2786,8 +2806,69 @@ struct dentry *d_alloc_parallel(struct dentry *paren= t, dput(dentry); goto retry; } + +/** + * d_alloc_parallel() - allocate a new dentry and ensure uniqueness + * @parent - dentry of the parent + * @name - name of the dentry within that parent. + * + * A new dentry is allocated and, providing it is unique, added to the + * relevant index. + * If an existing dentry is found with the same parent/name that is + * not d_in_lookup(), then that is returned instead. + * If the existing dentry is d_in_lookup(), d_alloc_parallel() waits for + * that lookup to complete before returning the dentry and then ensures the + * match is still valid. + * Thus if the returned dentry is d_in_lookup() then the caller has + * exclusive access until it completes the lookup. + * If the returned dentry is not d_in_lookup() then a lookup has + * already completed. + * + * The @name must already have ->hash set, as can be achieved + * by e.g. try_lookup_noperm(). + * + * Returns: the dentry, whether found or allocated, or an error %-ENOMEM. + */ +struct dentry *d_alloc_parallel(struct dentry *parent, + const struct qstr *name) +{ + return __d_alloc_parallel(parent, name, ALLOC_PARA_WAIT); +} EXPORT_SYMBOL(d_alloc_parallel); =20 +/** + * d_alloc_noblock() - find or allocate a new dentry + * @parent - dentry of the parent + * @name - name of the dentry within that parent. + * + * A new dentry is allocated and, providing it is unique, added to the + * relevant index. + * If an existing dentry is found with the same parent/name that is + * not d_in_lookup() then that is returned instead. + * If the existing dentry is d_in_lookup(), d_alloc_noblock() + * returns with error %-EWOULDBLOCK. + * Thus if the returned dentry is d_in_lookup() then the caller has + * exclusive access until it completes the lookup. + * If the returned dentry is not d_in_lookup() then a lookup has + * already completed. + * + * The @name need not already have ->hash set. + * + * Returns: the dentry, whether found or allocated, or an error + * %-ENOMEM, %-EWOULDBLOCK, and anything returned by ->d_hash(). + */ +struct dentry *d_alloc_noblock(struct dentry *parent, + struct qstr *name) +{ + struct dentry *de; + + de =3D try_lookup_noperm(name, parent); + if (!de) + de =3D __d_alloc_parallel(parent, name, ALLOC_PARA_FAIL); + return de; +} +EXPORT_SYMBOL(d_alloc_noblock); + /* * - Unhash the dentry * - Retrieve and clear the waitqueue head in dentry diff --git a/include/linux/dcache.h b/include/linux/dcache.h index 14b91a7d0bb6..85e8570cbd48 100644 --- a/include/linux/dcache.h +++ b/include/linux/dcache.h @@ -257,6 +257,7 @@ extern void d_delete(struct dentry *); extern struct dentry * d_alloc(struct dentry *, const struct qstr *); extern struct dentry * d_alloc_anon(struct super_block *); extern struct dentry * d_alloc_parallel(struct dentry *, const struct qstr= *); +extern struct dentry * d_alloc_noblock(struct dentry *, struct qstr *); extern struct dentry * d_splice_alias(struct inode *, struct dentry *); /* weird procfs mess; *NOT* exported */ extern struct dentry * d_splice_alias_ops(struct inode *, struct dentry *, --=20 2.50.0.107.gf914562f5916.dirty From nobody Wed Jun 17 07:22:57 2026 Received: from fout-a8-smtp.messagingengine.com (fout-a8-smtp.messagingengine.com [103.168.172.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A9DE227A916; Mon, 27 Apr 2026 04:06:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.151 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262794; cv=none; b=nUCoMTJYhnZUT4UEPZaF5Oez6fdiJ1NbLVetj2uXWzoT3rezdCJE4Rds/wEEeTUhA1e43p/qwRCsEO9TxRQk6AEsp4GqR1nYjT0qLImmotlqde6ph1Tj8mnT8jVEmXI8fOjbi9kV5aPCki+Gx3pnhTNyi2kEsG8A26X/EWd+Sw0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262794; c=relaxed/simple; bh=hPdDy+nq9BZvu+CByh4OHTQfVNub6SCjd8b0Ejvbz/Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VbZc5JgO8d34Hb+khh5A4s6fVOfkH2zxHr7zEzMmHMkF5fjf4ETI9uvBPAwgvO3dN+kFAz/zU12ifuS6ng7mE36afnjcACQIV4JbQXWT71f7GqaL6evWIFndTp9MXp8chQvEriSrnISuRgwJwUgByOP2sA5WfUuPF0w9knJdz0c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net; spf=pass smtp.mailfrom=ownmail.net; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b=bc1QJpAb; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=JAzMN8m9; arc=none smtp.client-ip=103.168.172.151 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ownmail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b="bc1QJpAb"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="JAzMN8m9" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfout.phl.internal (Postfix) with ESMTP id 04102EC03EF; Mon, 27 Apr 2026 00:06:32 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Mon, 27 Apr 2026 00:06:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ownmail.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to; s=fm2; t=1777262792; x=1777349192; bh=+evKnFZms5Q1zExWnLek6gAyl1qy9MDPzvO/EAV2rd4=; b= bc1QJpAbAYvKQPU+fMYntSxEJa83LpU6gos0ONSKgkn8Ot5UnDpCQTeNexaN47US Jba4lI2NLFwcmg+Ijtv4Hhbh0u1/6wvdhM5XYno0VQvncy469l0eVoTZrdZQKYkL PtohFaKqWPlCWFifHd/F4GvUEJZSRsDzoDiKGBP3ot90aJjsmMpBTIQdib8BHYT5 VNjI1qyOwltpAz2CiUDLbWnQkni2fYBxph2viXrwhJJixyoP64qS7rkE05xu/Lx9 BbCqbuDl/p9ZPyJkFuHptKfqL1C+ug5Ff/kY43SyoeRuxyFICNBMZpYBNoQSVgVM HwWUBnKU4frFtbCpJsP9OA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1777262792; x=1777349192; bh=+ evKnFZms5Q1zExWnLek6gAyl1qy9MDPzvO/EAV2rd4=; b=JAzMN8m9bnS/u4MUi tAlEhXDF6T3aNkl7jug3iJ/NiRx/R9DPxK/4SrfT3+C/GVQGotwsNNMwRkmQTfbh kHxqO4yXQZC2P/tpqKzq8X7i79ljwbETO7eINP9AqOxamjCSbqYEibyUzzpA0WrM qB48oiC6EAh9ZbW6G+7GbuQOTO9BaaxKx88YqL4sVePUu4QzRnCMgIqZc2VMvJRV FesnqqkNKqqwgBrzwz3PdkZYpW3VgB229rrL70mOa2I37HrPMoFwGzP20c9Yk7VD LlTFxumft6T5JrdWFG2BiQipTFE8JsP5o796mq7+qqEGiuVj7lq7uj9oWL5rITWe QC44A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdejjeeilecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffkffojghfrhgggfestdekredtredttdenucfhrhhomheppfgvihhluehr ohifnhcuoehnvghilhgssehofihnmhgrihhlrdhnvghtqeenucggtffrrghtthgvrhhnpe evveekffduueevhfeigefhgfdukedtleekjeeitdejudfgueekvdekffdvfedvudenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhgsse hofihnmhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeduiedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvhhirhhoseiivghnihhvrdhlihhnuhigrdhorhhgrdhukhdprh gtphhtthhopehlihhnuhigqdhunhhiohhnfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhg pdhrtghpthhtoheplhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprh gtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehlihhnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehmihhklhhoshesshiivghrvgguihdrhhhupdhrtghpthhtohepjhgrtg hksehsuhhsvgdrtgiipdhrtghpthhtohepjhhksehoiihlrggsshdrohhrgh X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Apr 2026 00:06:27 -0400 (EDT) From: NeilBrown To: Linus Torvalds , Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Trond Myklebust , Anna Schumaker , Miklos Szeredi , Amir Goldstein , Jeremy Kerr , Ard Biesheuvel Cc: linux-efi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 06/19] VFS: add d_duplicate() Date: Mon, 27 Apr 2026 14:01:24 +1000 Message-ID: <20260427040517.828226-7-neilb@ownmail.net> X-Mailer: git-send-email 2.50.0.107.gf914562f5916.dirty In-Reply-To: <20260427040517.828226-1-neilb@ownmail.net> References: <20260427040517.828226-1-neilb@ownmail.net> Reply-To: NeilBrown Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: NeilBrown Occasionally a single operation can require two sub-operations on the same name, and it is important that a d_alloc_parallel() (once that can be run unlocked) does not create another dentry with the same name between the operations. Two examples: 1/ rename where the target name (a positive dentry) needs to be "silly-renamed" to a temporary name so it will remain available on the server (NFS and AFS). Here the same name needs to be the subject of one rename, and the target of another. 2/ rename where the subject needs to be replaced with a white-out (shmemfs). Here the same name need to be the target of a rename and the target of a mknod() In both cases the original dentry is renamed to something else, and a replacement is instantiated, possibly as the target of d_move(), possibly by d_instantiate(). Currently d_alloc() is used to create the dentry and the exclusive lock on the parent ensures no other dentry is created. When d_alloc_parallel() is moved out of the parent lock, this will no longer be sufficient. In particular if the original is renamed away before the new is instantiated, there is a window where d_alloc_parallel() could create another name. "silly-rename" does work in this order. shmemfs whiteout doesn't open this hole but is essentially the same pattern and should use the same approach. The new d_duplicate() creates an in-lookup dentry with the same name as the original dentry, which must be hashed. There is no need to check if an in-lookup dentry exists with the same name as d_alloc_parallel() will never try add one while the hashed dentry exists. Once the new in-lookup is created, d_alloc_parallel() will find it and wait for it to complete, then use it. Signed-off-by: NeilBrown --- fs/dcache.c | 51 ++++++++++++++++++++++++++++++++++++++++++ include/linux/dcache.h | 1 + 2 files changed, 52 insertions(+) diff --git a/fs/dcache.c b/fs/dcache.c index dc06e70695d2..569a8ddf4c0d 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -1900,6 +1900,57 @@ struct dentry *d_alloc(struct dentry * parent, const= struct qstr *name) } EXPORT_SYMBOL(d_alloc); =20 +/** + * d_duplicate: duplicate a dentry for combined atomic operation + * @dentry: the dentry to duplicate + * + * Some rename operations need to be combined with another operation + * inside the filesystem. + * 1/ A cluster filesystem when renaming to an in-use file might need to + * first "silly-rename" that target out of the way before the main rename + * 2/ A filesystem that supports white-out might want to create a whiteout + * in place of the file being moved. + * + * For this they need two dentries which temporarily have the same name, + * before one is renamed. d_duplicate() provides for this. Given a + * positive hashed dentry, it creates a second in-lookup dentry. + * Because the original dentry exists, no other thread will try to + * create an in-lookup dentry, os there can be no race in this create. + * + * The caller should d_move() the original to a new name, often via a + * rename request, and should call d_lookup_done() on the newly created + * dentry. If the new is instantiated and the old MUST either be moved + * or dropped. + * + * Parent must be locked. + * + * Returns: an in-lookup dentry, or an error. + */ +struct dentry *d_duplicate(struct dentry *dentry) +{ + unsigned int hash =3D dentry->d_name.hash; + struct dentry *parent =3D dentry->d_parent; + struct hlist_bl_head *b =3D in_lookup_hash(parent, hash); + struct dentry *new =3D __d_alloc(parent->d_sb, &dentry->d_name); + + if (unlikely(!new)) + return ERR_PTR(-ENOMEM); + + new->d_flags |=3D DCACHE_PAR_LOOKUP; + spin_lock(&parent->d_lock); + new->d_parent =3D dget_dlock(parent); + hlist_add_head(&new->d_sib, &parent->d_children); + if (parent->d_flags & DCACHE_DISCONNECTED) + new->d_flags |=3D DCACHE_DISCONNECTED; + spin_unlock(&dentry->d_parent->d_lock); + + hlist_bl_lock(b); + hlist_bl_add_head(&new->d_in_lookup_hash, b); + hlist_bl_unlock(b); + return new; +} +EXPORT_SYMBOL(d_duplicate); + struct dentry *d_alloc_anon(struct super_block *sb) { return __d_alloc(sb, NULL); diff --git a/include/linux/dcache.h b/include/linux/dcache.h index 85e8570cbd48..3991f9988599 100644 --- a/include/linux/dcache.h +++ b/include/linux/dcache.h @@ -259,6 +259,7 @@ extern struct dentry * d_alloc_anon(struct super_block = *); extern struct dentry * d_alloc_parallel(struct dentry *, const struct qstr= *); extern struct dentry * d_alloc_noblock(struct dentry *, struct qstr *); extern struct dentry * d_splice_alias(struct inode *, struct dentry *); +struct dentry *d_duplicate(struct dentry *dentry); /* weird procfs mess; *NOT* exported */ extern struct dentry * d_splice_alias_ops(struct inode *, struct dentry *, const struct dentry_operations *); --=20 2.50.0.107.gf914562f5916.dirty From nobody Wed Jun 17 07:22:57 2026 Received: from fout-a8-smtp.messagingengine.com (fout-a8-smtp.messagingengine.com [103.168.172.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4B89535AC01; Mon, 27 Apr 2026 04:06:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.151 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262811; cv=none; b=OEL3OW4pQ+AFMqZ7j0vWWkuvugKDK7Jvu8zw5dmiy/TRRgQPYalUgB051sSfHfVHFYQfTSi7HnYAkNzlbOyP0Nz+moU9L2bEr4GuMrkKcz4W/VTg2DFVMQrAt3wKxwXF7WngM2t4UI1JohJHNajnUTFun3gky5/ZabM5qJbxDPQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262811; c=relaxed/simple; bh=Af17cpjWLrgjln+x15PYEXYO/pHIZybmrmOg/uu6FGs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sBrRPMvqElrXbc2NjWu3hdjW8K3mRTGVNq/v3GOtZvqRBAGdAEx4sT+/ivyt45riuPjgqXuE9cD3NDKYzT1BjsDnSEVCKdmn7sN/6v83AGUuqyVFU04xZ8kteu6akXx5/E317iJMtTCUE+dnRHBdEg4DOqbFGufcN1MO5gwLYBE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net; spf=pass smtp.mailfrom=ownmail.net; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b=QyxVJdxr; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=R23otq2G; arc=none smtp.client-ip=103.168.172.151 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ownmail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b="QyxVJdxr"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="R23otq2G" Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfout.phl.internal (Postfix) with ESMTP id 9575EEC03EF; Mon, 27 Apr 2026 00:06:46 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Mon, 27 Apr 2026 00:06:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ownmail.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to; s=fm2; t=1777262806; x=1777349206; bh=2Sazp1M0TdInI6mi6hF1QSnGjDghjOgL8lkwZNivMpc=; b= QyxVJdxrsn4Mx6G6wXw6rxDv3RQ1d108vFjLoBBhBzmRVoBRDhicrmszPcqC6YGX Z4RefjOrpb/Q/mKPInuDuq69EPUbKhw3tL6esu01iwgQDBeqq2DHcnnU1Hye6DPP xOiy5IdfY+v390KztQH27yKqWEB19HwsFYZKhWXZOERV4jQAz9kXPg3TnzysgKVx cQ//yPP0wtQwjQ9SppgiaSSanfZ/ajaKz3HOrJCOB/5EHkGCWZZWUUc09Skvmkkn RL9BFumBZUSeGlwlOWBH5qP68xUw1yqpoDWC1IL0XIEBqURBtBQ8H+EWAsjv4GYw LPN/6vLgATtrVxXRZ+b7/Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1777262806; x=1777349206; bh=2 Sazp1M0TdInI6mi6hF1QSnGjDghjOgL8lkwZNivMpc=; b=R23otq2GivT/UyOjd RB/ntwNtlOel3b0Jw6TgSOas1rVsPqF2uskubyAeYc9Xt3LUQ7RJQ+GNBEn3ysK+ x11YzskK4/+fCGzPjqdNoc6N60KfuWnchJNhBXcoChSwzaH7vmiOYg3ngvPHN4+O ZU5OA1xm/aVzXKGUwtkkbnphhMWBIrfDY/6j0eyszOztAAwyMP3twaeoAWSieXo2 jmje2AxG18mgh0ezk+lM3vLJHeUoq6Ai5UCul1Ue/mLmZM4lh2OjBSeiDnA/DgqY PjtBmF0+c8pAya+XibzxnnCUW5KiU8NsIcRAfG/yQCoGegMkbBdikwZufr67/LgH LK9kQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdejjeeikecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffkffojghfrhgggfestdekredtredttdenucfhrhhomheppfgvihhluehr ohifnhcuoehnvghilhgssehofihnmhgrihhlrdhnvghtqeenucggtffrrghtthgvrhhnpe evveekffduueevhfeigefhgfdukedtleekjeeitdejudfgueekvdekffdvfedvudenucev lhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhgsse hofihnmhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeduiedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvhhirhhoseiivghnihhvrdhlihhnuhigrdhorhhgrdhukhdprh gtphhtthhopehlihhnuhigqdhunhhiohhnfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhg pdhrtghpthhtoheplhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprh gtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehlihhnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehmihhklhhoshesshiivghrvgguihdrhhhupdhrtghpthhtohepjhgrtg hksehsuhhsvgdrtgiipdhrtghpthhtohepjhhksehoiihlrggsshdrohhrgh X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Apr 2026 00:06:42 -0400 (EDT) From: NeilBrown To: Linus Torvalds , Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Trond Myklebust , Anna Schumaker , Miklos Szeredi , Amir Goldstein , Jeremy Kerr , Ard Biesheuvel Cc: linux-efi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 07/19] VFS: Add LOOKUP_SHARED flag. Date: Mon, 27 Apr 2026 14:01:25 +1000 Message-ID: <20260427040517.828226-8-neilb@ownmail.net> X-Mailer: git-send-email 2.50.0.107.gf914562f5916.dirty In-Reply-To: <20260427040517.828226-1-neilb@ownmail.net> References: <20260427040517.828226-1-neilb@ownmail.net> Reply-To: NeilBrown Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: NeilBrown Some ->lookup handlers will need to drop and retake the parent lock, so they can safely use d_alloc_parallel(). ->lookup can be called with the parent lock either exclusive or shared. A new flag, LOOKUP_SHARED, tells ->lookup how the parent is locked. This is rather ugly, but will be gone soon after we move d_alloc_parallel() out of the directory lock as ->lookup() will *always* called with a shared lock on the parent. Signed-off-by: NeilBrown --- fs/namei.c | 7 ++++--- include/linux/namei.h | 3 ++- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/fs/namei.c b/fs/namei.c index a6349b31fdb6..e77ba9d31857 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -1928,7 +1928,7 @@ static noinline struct dentry *lookup_slow(const stru= ct qstr *name, struct inode *inode =3D dir->d_inode; struct dentry *res; inode_lock_shared(inode); - res =3D __lookup_slow(name, dir, flags); + res =3D __lookup_slow(name, dir, flags | LOOKUP_SHARED); inode_unlock_shared(inode); return res; } @@ -1942,7 +1942,7 @@ static struct dentry *lookup_slow_killable(const stru= ct qstr *name, =20 if (inode_lock_shared_killable(inode)) return ERR_PTR(-EINTR); - res =3D __lookup_slow(name, dir, flags); + res =3D __lookup_slow(name, dir, flags | LOOKUP_SHARED); inode_unlock_shared(inode); return res; } @@ -4413,6 +4413,7 @@ static struct dentry *lookup_open(struct nameidata *n= d, struct file *file, struct dentry *dentry; int error, create_error =3D 0; umode_t mode =3D op->mode; + unsigned int shared_flag =3D (op->open_flag & O_CREAT) ? 0 : LOOKUP_SHARE= D; =20 if (unlikely(IS_DEADDIR(dir_inode))) return ERR_PTR(-ENOENT); @@ -4480,7 +4481,7 @@ static struct dentry *lookup_open(struct nameidata *n= d, struct file *file, =20 if (d_in_lookup(dentry)) { struct dentry *res =3D dir_inode->i_op->lookup(dir_inode, dentry, - nd->flags); + nd->flags | shared_flag); d_lookup_done(dentry); if (unlikely(res)) { if (IS_ERR(res)) { diff --git a/include/linux/namei.h b/include/linux/namei.h index 2ad6dd9987b9..b3346a513d8f 100644 --- a/include/linux/namei.h +++ b/include/linux/namei.h @@ -37,8 +37,9 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT}; #define LOOKUP_CREATE BIT(17) /* ... in object creation */ #define LOOKUP_EXCL BIT(18) /* ... in target must not exist */ #define LOOKUP_RENAME_TARGET BIT(19) /* ... in destination of rename() */ +#define LOOKUP_SHARED BIT(20) /* Parent lock is held shared */ =20 -/* 4 spare bits for intent */ +/* 3 spare bits for intent */ =20 /* Scoping flags for lookup. */ #define LOOKUP_NO_SYMLINKS BIT(24) /* No symlink crossing. */ --=20 2.50.0.107.gf914562f5916.dirty From nobody Wed Jun 17 07:22:57 2026 Received: from fout-a8-smtp.messagingengine.com (fout-a8-smtp.messagingengine.com [103.168.172.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 299912877DE; Mon, 27 Apr 2026 04:07:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.151 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262828; cv=none; b=K9MoLvfU1emwgJOHjZ6nhfCA7WKTiR1YxKsPG1lVG+bs0GgxHqyGSTHXNy+uALoBfYtXBebymx8HHsG6yuirSMc+VIJkViXjZVNdu7dAY3QJLBenC2GsXk7Fto8eppMag8uioEDz18vx6hP8kYZebSZWZgpLWdtOYWsAlb0akk4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262828; c=relaxed/simple; bh=yRP77MAWO+gIHiR84B9F5QCRIoLxg6i5LGDL4a/5i6Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cveACFqVrStfrwJRe6S/fBbj/N7mrgH508JKNbnxqrF1WsUGUwwvEQex8WBu4OYABB16VCvsVZBqfHE7KGOVvG8JC+9WbKqK+wPdvWaQsBeOk1jZVthx/YxCZOhTjxYZuMMgYCp6RivTRBgU9aKQHrbqZtJgdabLjrm9zr4/6wY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net; spf=pass smtp.mailfrom=ownmail.net; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b=gFsra7bG; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=VHvOX9fH; arc=none smtp.client-ip=103.168.172.151 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ownmail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b="gFsra7bG"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="VHvOX9fH" Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfout.phl.internal (Postfix) with ESMTP id 6639DEC03EF; Mon, 27 Apr 2026 00:07:06 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Mon, 27 Apr 2026 00:07:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ownmail.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to; s=fm2; t=1777262826; x=1777349226; bh=zdXjCv6aJzC4DSxkackOkKHCbtNaMCphdlTQdbSEugA=; b= gFsra7bGf8UMphMuVAxQbRumNM2bR54fpb1xKK6YnsEfaCaRV24mMFdXlNG/913p zcRz+P+ly7tUcssyb8Mx/d3tDnKfMh/12U8q7jwIZuK0UEa30oaQruZuE57HauNC UiJI9EfjfHf85zJcjydqi6Qt+rxWroqYGhCXNP0qHgKHWOOPNZXoyomcpd8S/wSw z7/uqmFge1lkkTqUzq0ywuFXM+DXH4JP9YEV9wmIb2IzGWkWJ6iAR0DgVTela8FE PPVwDiYEnMhe2P3Ti/vGiWeeQ65VcYSXAZfrHRPZXY1lrmeZvs0xWkivaARdl4VV jhdWGBxeU4CrLNcWzwlv0Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1777262826; x=1777349226; bh=z dXjCv6aJzC4DSxkackOkKHCbtNaMCphdlTQdbSEugA=; b=VHvOX9fHObbSZZud6 RHElDtw62QGF62utVH+AXLsBO7NQxYgcZuZZ6Ib2omPOFXu8YVdiPwN3B0tXEUQk VFq2eaQH3Fml8ouh4jMz6+zy4hxfvv/SON0CUWPuE6eTLkri5KmT6N63gocftsJQ ZOcZbwM7DmwY0QpyNzJaPTKvWjEDv4Mz2lWMDnxcSz7lJjLgYtnLuHQclD3vFc13 FAB6p55Ze6hdZoepq7mSqufHH+AkLhucC8AZkE3a/vWN6q9nbrxmniPFL3Tbktko kHWzp7QjXeX14U7TBSymVaAIlHrK0xxVFHfTXSYE9ch4rDWQeLOAGaRBx/bcJ9Y4 YrQ8w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdejjeeikecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffkffojghfrhgggfestdekredtredttdenucfhrhhomheppfgvihhluehr ohifnhcuoehnvghilhgssehofihnmhgrihhlrdhnvghtqeenucggtffrrghtthgvrhhnpe evveekffduueevhfeigefhgfdukedtleekjeeitdejudfgueekvdekffdvfedvudenucev lhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhgsse hofihnmhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeduiedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvhhirhhoseiivghnihhvrdhlihhnuhigrdhorhhgrdhukhdprh gtphhtthhopehlihhnuhigqdhunhhiohhnfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhg pdhrtghpthhtoheplhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprh gtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehlihhnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehmihhklhhoshesshiivghrvgguihdrhhhupdhrtghpthhtohepjhgrtg hksehsuhhsvgdrtgiipdhrtghpthhtohepjhhksehoiihlrggsshdrohhrgh X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Apr 2026 00:07:01 -0400 (EDT) From: NeilBrown To: Linus Torvalds , Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Trond Myklebust , Anna Schumaker , Miklos Szeredi , Amir Goldstein , Jeremy Kerr , Ard Biesheuvel Cc: linux-efi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 08/19] VFS/xfs/ntfs: drop parent lock across d_alloc_parallel() in d_add_ci() Date: Mon, 27 Apr 2026 14:01:26 +1000 Message-ID: <20260427040517.828226-9-neilb@ownmail.net> X-Mailer: git-send-email 2.50.0.107.gf914562f5916.dirty In-Reply-To: <20260427040517.828226-1-neilb@ownmail.net> References: <20260427040517.828226-1-neilb@ownmail.net> Reply-To: NeilBrown Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: NeilBrown A proposed change will invert the lock ordering between d_alloc_parallel() and inode_lock() on the parent. When that happens it will not be safe to call d_alloc_parallel() while holding the parent lock - even shared. We don't need to keep the parent lock held when d_add_ci() is run - the VFS doesn't need it as dentry is exclusively held due to DCACHE_PAR_LOOKUP and the filesystem has finished its work. So drop and reclaim the lock (shared or exclusive as determined by LOOKUP_SHARED) to avoid future deadlock. Signed-off-by: NeilBrown --- fs/dcache.c | 18 +++++++++++++++++- fs/ntfs/namei.c | 4 +++- fs/xfs/xfs_iops.c | 3 ++- include/linux/dcache.h | 3 ++- 4 files changed, 24 insertions(+), 4 deletions(-) diff --git a/fs/dcache.c b/fs/dcache.c index 569a8ddf4c0d..a2ddfe811df3 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -2294,6 +2294,7 @@ EXPORT_SYMBOL(d_obtain_root); * @dentry: the negative dentry that was passed to the parent's lookup func * @inode: the inode case-insensitive lookup has found * @name: the case-exact name to be associated with the returned dentry + * @bool: %true if lookup was performed with LOOKUP_SHARED * * This is to avoid filling the dcache with case-insensitive names to the * same inode, only the actual correct case is stored in the dcache for @@ -2306,7 +2307,7 @@ EXPORT_SYMBOL(d_obtain_root); * the exact case, and return the spliced entry. */ struct dentry *d_add_ci(struct dentry *dentry, struct inode *inode, - struct qstr *name) + struct qstr *name, bool shared) { struct dentry *found, *res; =20 @@ -2319,6 +2320,17 @@ struct dentry *d_add_ci(struct dentry *dentry, struc= t inode *inode, iput(inode); return found; } + /* + * We are holding parent lock and so don't want to wait for a + * d_in_lookup() dentry. We can safely drop the parent lock and + * reclaim it as we have exclusive access to dentry as it is + * d_in_lookup() (so ->d_parent is stable) and we are near the + * end ->lookup() and will shortly drop the lock anyway. + */ + if (shared) + inode_unlock_shared(d_inode(dentry->d_parent)); + else + inode_unlock(d_inode(dentry->d_parent)); if (d_in_lookup(dentry)) { found =3D d_alloc_parallel(dentry->d_parent, name); if (IS_ERR(found) || !d_in_lookup(found)) { @@ -2332,6 +2344,10 @@ struct dentry *d_add_ci(struct dentry *dentry, struc= t inode *inode, return ERR_PTR(-ENOMEM); } } + if (shared) + inode_lock_shared(d_inode(dentry->d_parent)); + else + inode_lock_nested(d_inode(dentry->d_parent), I_MUTEX_PARENT); res =3D d_splice_alias(inode, found); if (res) { d_lookup_done(found); diff --git a/fs/ntfs/namei.c b/fs/ntfs/namei.c index 10894de519c3..30dddef43300 100644 --- a/fs/ntfs/namei.c +++ b/fs/ntfs/namei.c @@ -8,6 +8,7 @@ =20 #include #include +#include // for LOOKUP_SHARED =20 #include "ntfs.h" #include "time.h" @@ -310,7 +311,8 @@ static struct dentry *ntfs_lookup(struct inode *dir_ino= , struct dentry *dent, } nls_name.hash =3D full_name_hash(dent, nls_name.name, nls_name.len); =20 - dent =3D d_add_ci(dent, dent_inode, &nls_name); + dent =3D d_add_ci(dent, dent_inode, &nls_name, + !!(flags & LOOKUP_SHARED)); kfree(nls_name.name); return dent; =20 diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c index 325c2200c501..f03d832f1468 100644 --- a/fs/xfs/xfs_iops.c +++ b/fs/xfs/xfs_iops.c @@ -35,6 +35,7 @@ #include #include #include +#include // for LOOKUP_SHARED =20 /* * Directories have different lock order w.r.t. mmap_lock compared to regu= lar @@ -369,7 +370,7 @@ xfs_vn_ci_lookup( /* else case-insensitive match... */ dname.name =3D ci_name.name; dname.len =3D ci_name.len; - dentry =3D d_add_ci(dentry, VFS_I(ip), &dname); + dentry =3D d_add_ci(dentry, VFS_I(ip), &dname, !!(flags & LOOKUP_SHARED)); kfree(ci_name.name); return dentry; } diff --git a/include/linux/dcache.h b/include/linux/dcache.h index 3991f9988599..662b98185337 100644 --- a/include/linux/dcache.h +++ b/include/linux/dcache.h @@ -263,7 +263,8 @@ struct dentry *d_duplicate(struct dentry *dentry); /* weird procfs mess; *NOT* exported */ extern struct dentry * d_splice_alias_ops(struct inode *, struct dentry *, const struct dentry_operations *); -extern struct dentry * d_add_ci(struct dentry *, struct inode *, struct qs= tr *); +extern struct dentry * d_add_ci(struct dentry *, struct inode *, struct qs= tr *, + bool); extern bool d_same_name(const struct dentry *dentry, const struct dentry *= parent, const struct qstr *name); extern struct dentry *d_find_any_alias(struct inode *inode); --=20 2.50.0.107.gf914562f5916.dirty From nobody Wed Jun 17 07:22:57 2026 Received: from fout-a8-smtp.messagingengine.com (fout-a8-smtp.messagingengine.com [103.168.172.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7FDF023EAB3; Mon, 27 Apr 2026 04:07:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.151 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262836; cv=none; b=cu2likyR0tg0jiyGpWdHEwXa+EY0+WPGul+gnR2OHg+K6meAccqetOvl8M0GLzC3AT6OrZOZ8We4FG4XYioS1CgW3vvUDxpe5K4MhNuyshrreenfCKz5dBjvx5FA49DUenE4ISffgqp+5snnqxiTW5LQ/SVF6IuGBHyWHGEmGNc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262836; c=relaxed/simple; bh=n0RBYhb1fP4ASV0zBA39c1ZPWM/TE8hrkDBaS0wQeV0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HPWAWTh4catKJSqf061PW1QGhOL4eY80CgQFrkkIzvh+fc3YHrm0tgMy2KYGt6KjmUtGdFT3ooyEdRsn0dB3V0waIGisOnV/rR2tcO/k63A+b8IwV8wzeAmRL3bQST5woOjcP0jHjm0exclYzrFQFn6srzAJr8jsS1JevoR+vZ0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net; spf=pass smtp.mailfrom=ownmail.net; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b=H27rvNOb; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=DWDgnrtG; arc=none smtp.client-ip=103.168.172.151 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ownmail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b="H27rvNOb"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="DWDgnrtG" Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfout.phl.internal (Postfix) with ESMTP id 7BEE2EC03EF; Mon, 27 Apr 2026 00:07:14 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Mon, 27 Apr 2026 00:07:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ownmail.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to; s=fm2; t=1777262834; x=1777349234; bh=GR1euGmhNh9kvDlUiHAfiXoej5uoUlhCzq+/NqNURu4=; b= H27rvNObQ8Zyp8Ja3r/knWAtvfb0Q0LVCUftkmRqXxl/cGdfwuU9SKy6KXEchJHy L6eUrhCaOywiFf9vIvvZL4CxP6efvDIbzGCLsG5OPaaeLHmzOIC5tG+uuJakfcDo Kf4VoDzVfF3OSR1SW9rvM0XARsgX2ifdIu2mSFH4BmGvvlgisW5IQxtJzYyHxacE QB5A+RDBU+1qrBpf50O6EesZhGn/QJ825lIUtp9YIK3+N64L6f6qSO/XMXZbndyl 01AGFxFCXoQMyUuhurhioTOPPdfHRtbp8k7EFfBgaYpDQcxbJrOh1lVx+OKEerxI /Rk3q8W7Iw/+0dgb5gTwRA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1777262834; x=1777349234; bh=G R1euGmhNh9kvDlUiHAfiXoej5uoUlhCzq+/NqNURu4=; b=DWDgnrtGnH50h2Blx zAJyKUyiWcwokHQ4hrxKEUCVCvgY5iJjySZUmrpVnH3vPP+O4SZxgK6xFWUbGJPK GZ9ejRJg1/iKzVcjp1xMaNWjamTSAd6VAb6loXeaJGFjhiNCj8ckn5qo765MEMbE mOte97paDYoTzZnxTP77xOVSsaS9pHm7Cy0rj1pEJxxUWrBU0pmdPhdyto7JWs7W rT0wAqX9IIMBka4dP1w8xFbIRh7Ho4A/C/eXWUukmSwOy+dN7vGpDDPRg7+157fs un+T2D7Mbh2otpMaqaoP47zlw5nC4U62TsNbq8uMh99IzSZ7ke1ffZXrZ3KppHX5 f74rQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdejjeeikecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffkffojghfrhgggfestdekredtredttdenucfhrhhomheppfgvihhluehr ohifnhcuoehnvghilhgssehofihnmhgrihhlrdhnvghtqeenucggtffrrghtthgvrhhnpe evveekffduueevhfeigefhgfdukedtleekjeeitdejudfgueekvdekffdvfedvudenucev lhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhgsse hofihnmhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeduiedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvhhirhhoseiivghnihhvrdhlihhnuhigrdhorhhgrdhukhdprh gtphhtthhopehlihhnuhigqdhunhhiohhnfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhg pdhrtghpthhtoheplhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprh gtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehlihhnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehmihhklhhoshesshiivghrvgguihdrhhhupdhrtghpthhtohepjhgrtg hksehsuhhsvgdrtgiipdhrtghpthhtohepjhhksehoiihlrggsshdrohhrgh X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Apr 2026 00:07:09 -0400 (EDT) From: NeilBrown To: Linus Torvalds , Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Trond Myklebust , Anna Schumaker , Miklos Szeredi , Amir Goldstein , Jeremy Kerr , Ard Biesheuvel Cc: linux-efi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 09/19] ovl: stop using lookup_one() in iterate_shared() handling. Date: Mon, 27 Apr 2026 14:01:27 +1000 Message-ID: <20260427040517.828226-10-neilb@ownmail.net> X-Mailer: git-send-email 2.50.0.107.gf914562f5916.dirty In-Reply-To: <20260427040517.828226-1-neilb@ownmail.net> References: <20260427040517.828226-1-neilb@ownmail.net> Reply-To: NeilBrown Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: NeilBrown lookup_one() is expected to be removed as it does not fit well with proposed changes to directory locking. Specifically d_alloc_parallel() will be ordered outside of i_rwsem and as iterate_shared() is called with i_rwsem held it is not safe to call d_alloc_parallel(). We can instead call d_alloc_noblock() and then call the ->lookup, but that can fail if there is a lookup attempt concurrent with the readdir(). ovl cannot afford for the lookup to fail as that could produce incorrect results, and it cannot safely drop i_rwsem temporarily and that could introduce races with handling of the directory cache. Instead we rely on the fact that ovl_iterate() has an exclusive lock on the directory, so any concurrent lookup will wait for the ovl_iterate() call to complete. We allocate a separate dentry and if the lookup is successful, it is hashed with the result. When the concurrent lookup gets i_rwsem it mustn't do its own lookup - it must use the existing dentry. This is found, if it exists, using try_lookup_noperm(). Signed-off-by: NeilBrown --- fs/overlayfs/namei.c | 12 ++++++++++++ fs/overlayfs/readdir.c | 24 ++++++++++++++++++++++-- 2 files changed, 34 insertions(+), 2 deletions(-) diff --git a/fs/overlayfs/namei.c b/fs/overlayfs/namei.c index ca899fdfaafd..69032eb2b1e2 100644 --- a/fs/overlayfs/namei.c +++ b/fs/overlayfs/namei.c @@ -1385,6 +1385,7 @@ struct dentry *ovl_lookup(struct inode *dir, struct d= entry *dentry, struct ovl_fs *ofs =3D OVL_FS(dentry->d_sb); struct ovl_entry *poe =3D OVL_E(dentry->d_parent); bool check_redirect =3D (ovl_redirect_follow(ofs) || ofs->numdatalayer); + struct dentry *alias; int err; struct ovl_lookup_ctx ctx =3D { .dentry =3D dentry, @@ -1399,6 +1400,17 @@ struct dentry *ovl_lookup(struct inode *dir, struct = dentry *dentry, if (dentry->d_name.len > ofs->namelen) return ERR_PTR(-ENAMETOOLONG); =20 + /* + * The existance of this in-lookup dentry might have forced + * readdir to do the lookup with a new dentry. If so we must + * return that one. + */ + alias =3D try_lookup_noperm(&QSTR_LEN(dentry->d_name.name, + dentry->d_name.len), + dentry->d_parent); + if (alias && !IS_ERR(alias)) + return alias; + with_ovl_creds(dentry->d_sb) err =3D ovl_lookup_layers(&ctx, &d); =20 diff --git a/fs/overlayfs/readdir.c b/fs/overlayfs/readdir.c index 1dcc75b3a90f..e03b32491941 100644 --- a/fs/overlayfs/readdir.c +++ b/fs/overlayfs/readdir.c @@ -574,8 +574,28 @@ static int ovl_cache_update(const struct path *path, s= truct ovl_cache_entry *p, } } /* This checks also for xwhiteouts */ - this =3D lookup_one(mnt_idmap(path->mnt), &QSTR_LEN(p->name, p->len), dir= ); - if (IS_ERR_OR_NULL(this) || !this->d_inode) { + this =3D d_alloc_noblock(dir, &QSTR_LEN(p->name, p->len)); + if (this =3D=3D ERR_PTR(-EWOULDBLOCK)) { + /* + * Some other thead is looking up this name and will + * block on i_rwsem before it can complete the lookup. + * We will do the lookup in a new dentry and when that + * lookup gets a turn it will find and return this + * dentry. + */ + this =3D d_alloc_name(dir, p->name); + } + if (!IS_ERR(this) && !d_unhashed(this)) { + /* Either we got an in-lookup or we made our own unhashed */ + struct dentry *alias =3D ovl_lookup(dir->d_inode, this, 0); + + if (alias) { + d_lookup_done(this); + dput(this); + this =3D alias; + } + } + if (IS_ERR(this) || !this->d_inode) { /* Mark a stale entry */ p->is_whiteout =3D true; if (IS_ERR(this)) { --=20 2.50.0.107.gf914562f5916.dirty From nobody Wed Jun 17 07:22:57 2026 Received: from fhigh-a5-smtp.messagingengine.com (fhigh-a5-smtp.messagingengine.com [103.168.172.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E8385258EC1; Mon, 27 Apr 2026 04:07:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.156 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262844; cv=none; b=IZA275hYdWWVgoGA+IVB33JW2GvqrGI7XvGOUwDJwWxQKzukeBZl9LmxisIIziGGvQFeNrFIeVWQqx5NafsAVjytIKoentGMkoCGv4gQwteLUUnZ7BSlnAPfqTG1NnABNrFCPTgqITIpfog9x5exmLKxF4h1tjrSx84wnTfg0ow= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262844; c=relaxed/simple; bh=VecR1S/RUz2yVvlcP8kNlxqqZIjt+aDgC768AxT9B68=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TasECPSU0ZO4GibHtgYyrbNlmbbVNIfH/JXKuYt454HBZE1ikqbSWc/laI87nGHQMF8OY+KDA5zSI2bEjT0NrO26Sp5/N73rsnhnDVoCoagEOKx9RtGgU+I1csySydWmV9w/WL8oJLDtYQzyIaBxVOsp9G3ZgOu4e0So2ophI+8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net; spf=pass smtp.mailfrom=ownmail.net; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b=aWucrkuP; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=UEhqmDtK; arc=none smtp.client-ip=103.168.172.156 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ownmail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b="aWucrkuP"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="UEhqmDtK" Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.phl.internal (Postfix) with ESMTP id 5962114000B0; Mon, 27 Apr 2026 00:07:22 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Mon, 27 Apr 2026 00:07:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ownmail.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to; s=fm2; t=1777262842; x=1777349242; bh=4qLfGt5u8e8xG1LfUYl9b2VNKtzHCyChlkSyeX9DFOM=; b= aWucrkuPdh0hDTFVIHIJ/z2l7UWezBybhVUerOuTHSLnFJVBEpBarf+NL+CA8AgI oOSbSdZH0wuEOtCfotVNlCVnMlTRoX9QqrRkAUz4jFuJ8KJx4lDAZ2x+LPIVxWGE aW2s2B4npbPYlqlh6eyD6eBkWUOu5lNGkQzr1z2zHDA9QxLxihVS+ZqWYeRTRWmJ T/YqRlIv99uxO4tU1RJHrCFSBLvfst1K94gf/Wk4YCmkshnS7dFtNQCVEaQHou9s ekXgouUal1wjvAflJK01tuRCZx/BsjBR9aufi5znxI23lifhC5SqWScYcaOpd4ol FhoaHFvjZhuvlv5zZ2bgIw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1777262842; x=1777349242; bh=4 qLfGt5u8e8xG1LfUYl9b2VNKtzHCyChlkSyeX9DFOM=; b=UEhqmDtKrJko5r1F4 3Cx8eNHhkP+oT7harB7vebmP3i5eG7yKVuRQJYttvu5D51+gGSXmf6bRH57RhQLQ c+ZACvYtZOiV1KWmzuyAfK5j1pbQvBqB3mwEAPwq+xw13x0ma7NqaPGkgACeemEj ITtsA/goCesJ73oz75ZAzzaujGZ1eoQffM7RPjNnCBRZojMvPv8U5eBprhYSveV2 ivTM79k0e76hnY3jhOlKt5XYE8V9utto9487fm7175Ca14UjS2bL/2ThKmMArMpK 6XY+9zNU4METKyBjrYlXSZ3x6ZuhnSyGrQWcTi1S/y0PnLiLcKbvl11gXkBuNwzu Uv83Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdejjeeikecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffkffojghfrhgggfestdekredtredttdenucfhrhhomheppfgvihhluehr ohifnhcuoehnvghilhgssehofihnmhgrihhlrdhnvghtqeenucggtffrrghtthgvrhhnpe evveekffduueevhfeigefhgfdukedtleekjeeitdejudfgueekvdekffdvfedvudenucev lhhushhtvghrufhiiigvpeefnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhgsse hofihnmhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeduiedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvhhirhhoseiivghnihhvrdhlihhnuhigrdhorhhgrdhukhdprh gtphhtthhopehlihhnuhigqdhunhhiohhnfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhg pdhrtghpthhtoheplhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprh gtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehlihhnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehmihhklhhoshesshiivghrvgguihdrhhhupdhrtghpthhtohepjhgrtg hksehsuhhsvgdrtgiipdhrtghpthhtohepjhhksehoiihlrggsshdrohhrgh X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Apr 2026 00:07:17 -0400 (EDT) From: NeilBrown To: Linus Torvalds , Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Trond Myklebust , Anna Schumaker , Miklos Szeredi , Amir Goldstein , Jeremy Kerr , Ard Biesheuvel Cc: linux-efi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 10/19] VFS/ovl: add d_alloc_noblock_return() Date: Mon, 27 Apr 2026 14:01:28 +1000 Message-ID: <20260427040517.828226-11-neilb@ownmail.net> X-Mailer: git-send-email 2.50.0.107.gf914562f5916.dirty In-Reply-To: <20260427040517.828226-1-neilb@ownmail.net> References: <20260427040517.828226-1-neilb@ownmail.net> Reply-To: NeilBrown Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: NeilBrown ovl_lookup currently needs to check if a dentry with the same name has already been added to the dcache as readdir might need to do. This is an unnecessary performance cost to manage a rare race. If ovl could know which in-lookup dentries raced with readdir, it could limit the extra lookup to just those. So add d_alloc_noblock_return() which provides the in-lookup dentry when it returns -EWOULDBLOCK. ovl_readdir() can use this this and flag the dentry such that ovl_lookup() and easily check if a repeat lookup is needed. Signed-off-by: NeilBrown --- fs/dcache.c | 50 ++++++++++++++++++++++++++++++++++++---- fs/overlayfs/namei.c | 23 ++++++++++-------- fs/overlayfs/overlayfs.h | 2 ++ fs/overlayfs/readdir.c | 7 ++++-- include/linux/dcache.h | 2 ++ 5 files changed, 68 insertions(+), 16 deletions(-) diff --git a/fs/dcache.c b/fs/dcache.c index a2ddfe811df3..2f11257b725b 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -2749,7 +2749,8 @@ enum alloc_para { static inline struct dentry *__d_alloc_parallel(struct dentry *parent, const struct qstr *name, - enum alloc_para how) + enum alloc_para how, + struct dentry **dentryp) { unsigned int hash =3D name->hash; struct hlist_bl_head *b =3D in_lookup_hash(parent, hash); @@ -2836,7 +2837,10 @@ struct dentry *__d_alloc_parallel(struct dentry *par= ent, case ALLOC_PARA_FAIL: spin_unlock(&dentry->d_lock); dput(new); - dput(dentry); + if (dentryp) + *dentryp =3D dentry; + else + dput(dentry); return ERR_PTR(-EWOULDBLOCK); case ALLOC_PARA_WAIT: wait_var_event_spinlock(&dentry->d_flags, @@ -2899,7 +2903,7 @@ struct dentry *__d_alloc_parallel(struct dentry *pare= nt, struct dentry *d_alloc_parallel(struct dentry *parent, const struct qstr *name) { - return __d_alloc_parallel(parent, name, ALLOC_PARA_WAIT); + return __d_alloc_parallel(parent, name, ALLOC_PARA_WAIT, NULL); } EXPORT_SYMBOL(d_alloc_parallel); =20 @@ -2931,11 +2935,49 @@ struct dentry *d_alloc_noblock(struct dentry *paren= t, =20 de =3D try_lookup_noperm(name, parent); if (!de) - de =3D __d_alloc_parallel(parent, name, ALLOC_PARA_FAIL); + de =3D __d_alloc_parallel(parent, name, ALLOC_PARA_FAIL, NULL); return de; } EXPORT_SYMBOL(d_alloc_noblock); =20 +/** + * d_alloc_noblock_return() - find or allocate a new dentry + * @parent - dentry of the parent + * @name - name of the dentry within that parent. + * @dentryp - place to store the blocking dentry + * + * A new dentry is allocated and, providing it is unique, added to the + * relevant index. + * If an existing dentry is found with the same parent/name that is + * not d_in_lookup() then that is returned instead. + * If the existing dentry is d_in_lookup(), d_alloc_noblock() + * returns with error %-EWOULDBLOCK and the blocking dentry is passed + * in @dentryp. The dentry must be dput() by the caller. + * + * Thus if the returned dentry is d_in_lookup() then the caller has + * exclusive access until it completes the lookup. + * If the returned dentry is not d_in_lookup() then a lookup has + * already completed. + * + * The @name need not already have ->hash set. + * + * Returns: the dentry, whether found or allocated, or an error + * %-ENOMEM, %-EWOULDBLOCK, and anything returned by ->d_hash(). + */ +struct dentry *d_alloc_noblock_return(struct dentry *parent, + struct qstr *name, + struct dentry **dentryp) +{ + struct dentry *de; + + de =3D try_lookup_noperm(name, parent); + if (!de) + de =3D __d_alloc_parallel(parent, name, ALLOC_PARA_FAIL, + dentryp); + return de; +} +EXPORT_SYMBOL(d_alloc_noblock_return); + /* * - Unhash the dentry * - Retrieve and clear the waitqueue head in dentry diff --git a/fs/overlayfs/namei.c b/fs/overlayfs/namei.c index 69032eb2b1e2..524e661c3c8d 100644 --- a/fs/overlayfs/namei.c +++ b/fs/overlayfs/namei.c @@ -1400,16 +1400,19 @@ struct dentry *ovl_lookup(struct inode *dir, struct= dentry *dentry, if (dentry->d_name.len > ofs->namelen) return ERR_PTR(-ENAMETOOLONG); =20 - /* - * The existance of this in-lookup dentry might have forced - * readdir to do the lookup with a new dentry. If so we must - * return that one. - */ - alias =3D try_lookup_noperm(&QSTR_LEN(dentry->d_name.name, - dentry->d_name.len), - dentry->d_parent); - if (alias && !IS_ERR(alias)) - return alias; + if (ovl_dentry_test_flag(OVL_E_RACED_READDIR, dentry)) { + ovl_dentry_clear_flag(OVL_E_RACED_READDIR, dentry); + /* + * The existance of this in-lookup dentry might have + * forced readdir to do the lookup with a new dentry. + * If so we must return that one. + */ + alias =3D try_lookup_noperm(&QSTR_LEN(dentry->d_name.name, + dentry->d_name.len), + dentry->d_parent); + if (alias && !IS_ERR(alias)) + return alias; + } =20 with_ovl_creds(dentry->d_sb) err =3D ovl_lookup_layers(&ctx, &d); diff --git a/fs/overlayfs/overlayfs.h b/fs/overlayfs/overlayfs.h index b75df37f70ac..bd6f1a25aca1 100644 --- a/fs/overlayfs/overlayfs.h +++ b/fs/overlayfs/overlayfs.h @@ -71,6 +71,8 @@ enum ovl_entry_flag { OVL_E_CONNECTED, /* Lower stack may contain xwhiteout entries */ OVL_E_XWHITEOUTS, + /* dentry was found in-lookup during readdir */ + OVL_E_RACED_READDIR, }; =20 enum { diff --git a/fs/overlayfs/readdir.c b/fs/overlayfs/readdir.c index e03b32491941..e483bd939a8c 100644 --- a/fs/overlayfs/readdir.c +++ b/fs/overlayfs/readdir.c @@ -553,7 +553,7 @@ static int ovl_cache_update(const struct path *path, st= ruct ovl_cache_entry *p, { struct dentry *dir =3D path->dentry; struct ovl_fs *ofs =3D OVL_FS(dir->d_sb); - struct dentry *this =3D NULL; + struct dentry *this =3D NULL, *in_lookup; enum ovl_path_type type; u64 ino =3D p->real_ino; int xinobits =3D ovl_xino_bits(ofs); @@ -574,7 +574,8 @@ static int ovl_cache_update(const struct path *path, st= ruct ovl_cache_entry *p, } } /* This checks also for xwhiteouts */ - this =3D d_alloc_noblock(dir, &QSTR_LEN(p->name, p->len)); + this =3D d_alloc_noblock_return(dir, &QSTR_LEN(p->name, p->len), + &in_lookup); if (this =3D=3D ERR_PTR(-EWOULDBLOCK)) { /* * Some other thead is looking up this name and will @@ -583,6 +584,8 @@ static int ovl_cache_update(const struct path *path, st= ruct ovl_cache_entry *p, * lookup gets a turn it will find and return this * dentry. */ + ovl_dentry_set_flag(OVL_E_RACED_READDIR, in_lookup); + dput(in_lookup); this =3D d_alloc_name(dir, p->name); } if (!IS_ERR(this) && !d_unhashed(this)) { diff --git a/include/linux/dcache.h b/include/linux/dcache.h index 662b98185337..db7cdcbac775 100644 --- a/include/linux/dcache.h +++ b/include/linux/dcache.h @@ -258,6 +258,8 @@ extern struct dentry * d_alloc(struct dentry *, const s= truct qstr *); extern struct dentry * d_alloc_anon(struct super_block *); extern struct dentry * d_alloc_parallel(struct dentry *, const struct qstr= *); extern struct dentry * d_alloc_noblock(struct dentry *, struct qstr *); +extern struct dentry * d_alloc_noblock_return(struct dentry *, struct qstr= *, + struct dentry **); extern struct dentry * d_splice_alias(struct inode *, struct dentry *); struct dentry *d_duplicate(struct dentry *dentry); /* weird procfs mess; *NOT* exported */ --=20 2.50.0.107.gf914562f5916.dirty From nobody Wed Jun 17 07:22:57 2026 Received: from fout-a8-smtp.messagingengine.com (fout-a8-smtp.messagingengine.com [103.168.172.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BCF6F27A916; Mon, 27 Apr 2026 04:07:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.151 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262852; cv=none; b=smTnbsdwuLaFueqpWApfaAWkNSHhjzAfpGLTRrEeVgoyELRqrZopTbZc3ivPHS1k4d7lt+n61oiqC0R8b36jgruz81RcNWJ40iOwHpuc0PWo+adcbj1+e74ytdq3MghyI9FtNrRkDUiawJarRcbgKM++6xWRMX/PqXyUVpk1oUg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262852; c=relaxed/simple; bh=Ry03XapnV8ZPqRwD/otU1U6sq93iLJCjUmdAQ3JSF0k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=i+GKvBd3aNvimZWgy7F2HbrCA+4irrvCIHTNQzESmCNJfB+PbJvbT2Pw7zdQT+Kl5rdXIe/3UEyBqfOekBp53/rPyDqGhi58vpvTv5IW4nnNjELbdDeWRzEJL0epDD7YXDzOJ9Q9YNXwJQ4tnoowio36qt1gwU9QzMEKDoSjoUY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net; spf=pass smtp.mailfrom=ownmail.net; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b=e0tiocWc; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=p4mRIl61; arc=none smtp.client-ip=103.168.172.151 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ownmail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b="e0tiocWc"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="p4mRIl61" Received: from phl-compute-07.internal (phl-compute-07.internal [10.202.2.47]) by mailfout.phl.internal (Postfix) with ESMTP id 029E8EC03EF; Mon, 27 Apr 2026 00:07:30 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-07.internal (MEProxy); Mon, 27 Apr 2026 00:07:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ownmail.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to; s=fm2; t=1777262849; x=1777349249; bh=V1Hs5eklgfQn0H62/n/RsRquBHKKGkv3SWjXFgqWxeg=; b= e0tiocWcJeBFeHuA5Zoj1O729A0fdUG37W01YmLRh6FhslRIR5noVjJ8r3ggkvye FGxcwqUSIav/8W6ncfZl4c5MVbekdl7kncuXIlIaZNoToWZWLXH684lXDqczzQ8G HmLut2f3iO5Cuc+uOg8Ypf9r5i/lJLmVlO1myX6ZHzRquESI2BWHanaoTEILk+v0 NacqYs5HqTZSJP2nEggrx6PdGjE5h+NlCyE8zizTkbOoAyRS49LkMZ1BhJ86tyfQ fkriInG9qvxGhc2UzrP2Wz4VmkD0lme6gMHbQXTuolFegttaf9KrfBzI7Wgj4gfX VCEWZ0LX+8Aiki2CgGs53A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1777262849; x=1777349249; bh=V 1Hs5eklgfQn0H62/n/RsRquBHKKGkv3SWjXFgqWxeg=; b=p4mRIl610gvuGSfiC N8oRLAKLafsXb7EaQRcqYPiR3ZlQL+/E5tYRIgkjndVTm5gdtHpZl1eIxJC5CyFR 3YI4PcI9o43Bgj3pQFrokiEAbWntDAkX1eRcuDN0Gn1FCP0EZN+m/o1uRgIlxQuD tBwikkbUkKK7cVvlhKD4el+xv1Hqyi+qCPdPlcbmSsX8cfdP5D24nUNJiUEwlPGo 7Ynr1X3yhYJdvrQWirHnRwCCg/6qaLFxMcW8mRAIggPZA0jlMj3g48xGw9AKqBCL kgLzC6gOYFZc+gHSg4WO9/sq6n8uW+BIQ2IoW6O/bNXdc65+CqkcPP9dMt7wbG2C dx1xw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdejjeeikecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffkffojghfrhgggfestdekredtredttdenucfhrhhomheppfgvihhluehr ohifnhcuoehnvghilhgssehofihnmhgrihhlrdhnvghtqeenucggtffrrghtthgvrhhnpe evveekffduueevhfeigefhgfdukedtleekjeeitdejudfgueekvdekffdvfedvudenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhgsse hofihnmhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeduiedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvhhirhhoseiivghnihhvrdhlihhnuhigrdhorhhgrdhukhdprh gtphhtthhopehlihhnuhigqdhunhhiohhnfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhg pdhrtghpthhtoheplhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprh gtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehlihhnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehmihhklhhoshesshiivghrvgguihdrhhhupdhrtghpthhtohepjhgrtg hksehsuhhsvgdrtgiipdhrtghpthhtohepjhhksehoiihlrggsshdrohhrgh X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Apr 2026 00:07:25 -0400 (EDT) From: NeilBrown To: Linus Torvalds , Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Trond Myklebust , Anna Schumaker , Miklos Szeredi , Amir Goldstein , Jeremy Kerr , Ard Biesheuvel Cc: linux-efi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 11/19] efivarfs: use d_alloc_name() Date: Mon, 27 Apr 2026 14:01:29 +1000 Message-ID: <20260427040517.828226-12-neilb@ownmail.net> X-Mailer: git-send-email 2.50.0.107.gf914562f5916.dirty In-Reply-To: <20260427040517.828226-1-neilb@ownmail.net> References: <20260427040517.828226-1-neilb@ownmail.net> Reply-To: NeilBrown Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: NeilBrown efivarfs() is one of the few remaining users of d_alloc(). Other similar filesystems use d_alloc_name() in the same circumstances. Now that d_alloc_name() supports ->d_hash (providing that it never fails), change efivarfs to use that. Signed-off-by: NeilBrown --- fs/efivarfs/super.c | 26 +++----------------------- 1 file changed, 3 insertions(+), 23 deletions(-) diff --git a/fs/efivarfs/super.c b/fs/efivarfs/super.c index 1c5224cf183e..232d9757804c 100644 --- a/fs/efivarfs/super.c +++ b/fs/efivarfs/super.c @@ -189,26 +189,6 @@ static const struct dentry_operations efivarfs_d_ops = =3D { .d_hash =3D efivarfs_d_hash, }; =20 -static struct dentry *efivarfs_alloc_dentry(struct dentry *parent, char *n= ame) -{ - struct dentry *d; - struct qstr q; - int err; - - q.name =3D name; - q.len =3D strlen(name); - - err =3D efivarfs_d_hash(parent, &q); - if (err) - return ERR_PTR(err); - - d =3D d_alloc(parent, &q); - if (d) - return d; - - return ERR_PTR(-ENOMEM); -} - bool efivarfs_variable_is_present(efi_char16_t *variable_name, efi_guid_t *vendor, void *data) { @@ -263,9 +243,9 @@ static int efivarfs_create_dentry(struct super_block *s= b, efi_char16_t *name16, memcpy(entry->var.VariableName, name16, name_size); memcpy(&(entry->var.VendorGuid), &vendor, sizeof(efi_guid_t)); =20 - dentry =3D efivarfs_alloc_dentry(root, name); - if (IS_ERR(dentry)) { - err =3D PTR_ERR(dentry); + dentry =3D d_alloc_name(root, name); + if (!dentry) { + err =3D -ENOMEM; goto fail_inode; } =20 --=20 2.50.0.107.gf914562f5916.dirty From nobody Wed Jun 17 07:22:57 2026 Received: from fhigh-a5-smtp.messagingengine.com (fhigh-a5-smtp.messagingengine.com [103.168.172.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BB5A02749ED; Mon, 27 Apr 2026 04:07:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.156 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262858; cv=none; b=sIDcSJ1a9P43YWqbGbTXaUGOKza+uvDzT98KDTcZy1eyxmFpj7AH5vzqThnI/o+uShAFl0kZBRtsIQ5RHXBz+ZOrDpteT/73GVYxlGLdPDaWL8Xqlaem9kHeIa5fUSmesojuiD1QMIkLsKxGWSORs3aJh/2fcoHishdYks3uAxU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262858; c=relaxed/simple; bh=DFrp9NHxbOh7DcW+macG4cAgQAoWvIrKkUHLuu82auc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mZFWQixEaaXBoy/yRBoz0J6u4Bl0TYBrw/mNpNWSKK1gY2C5lnyXSsd5bB4ANAvebzHM1gredw50i5gbDCI9bCowguda5cFPz4603B7hDGzazTOJhn4G/4Rlh4R/qzIz7uzM/uKhDU6oINiLSxtnhvD45n1E5QFBEIEM6Y/IK6Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net; spf=pass smtp.mailfrom=ownmail.net; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b=Ohjtv5HI; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=urpFUAP1; arc=none smtp.client-ip=103.168.172.156 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ownmail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b="Ohjtv5HI"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="urpFUAP1" Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.phl.internal (Postfix) with ESMTP id 1283114000B0; Mon, 27 Apr 2026 00:07:37 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Mon, 27 Apr 2026 00:07:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ownmail.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to; s=fm2; t=1777262857; x=1777349257; bh=/lh7HUK0TKvg2/UYrerSNegrbJ1j2gtRpk+NrmqwPSE=; b= Ohjtv5HIy8kwh11+SsbiMh/ABYNn7tIDUSeS+YjTYnlGaK+MUrfMmy/lPZzSakIm qSpxEroqMZoMKcynjr3F4TD/a1G7JllgE2hGTA9YBwsMWEUXdckloenITYX5EU0/ vhwLEQss1QjJSrk8SY2zTJy7ig8rihhmvonyFE67ukIGVH1Uu6NZuOzDjWlH1mAl GfevQzGWlkfxISFBUhNqt9t+6tLrwqZY4yrAYNdR/noTQ+eHHBy/uvxP73s43WF8 lQx8dYTvFFr7GLe54T4DfymVPmT09k4lHjRh6e6czMs3UiGSXoK+5SKrvmbgrSxs urnCldWSI0OlC69DmlLZwQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1777262857; x=1777349257; bh=/ lh7HUK0TKvg2/UYrerSNegrbJ1j2gtRpk+NrmqwPSE=; b=urpFUAP1WTt4BiS5v RwpHBxcuy02t5Rs5R0Rmq7j3UXSp2BSHyEjcDzmFrgoRQZirjIl15YizH3fzFsUq B+U8F/S/2Yj7fmp8v+/jOaGHodt96ivrgEcRehNe1CKnmOZ7FRnYL4GKmOitSTkT fmIubIbqmpttb1IhIMPKcFaoBnp5vaISfsk1yHXfcyAvK92Aeye5yJcWsmix6KsR XhDJeyYaknB7oZGXM5iUgA6ROuUPYkPDtPNNlRX4z+2z8ljDh7BvpM2bLe0milI4 vwO2ErvrIeQVSKJlu8Be8O4Po7w+OEgkdUGh+nXDWQLVimvsy4IOUenIq1G4MlZZ bo3rA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdejjeeikecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffkffojghfrhgggfestdekredtredttdenucfhrhhomheppfgvihhluehr ohifnhcuoehnvghilhgssehofihnmhgrihhlrdhnvghtqeenucggtffrrghtthgvrhhnpe evveekffduueevhfeigefhgfdukedtleekjeeitdejudfgueekvdekffdvfedvudenucev lhhushhtvghrufhiiigvpeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhgsse hofihnmhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeduiedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvhhirhhoseiivghnihhvrdhlihhnuhigrdhorhhgrdhukhdprh gtphhtthhopehlihhnuhigqdhunhhiohhnfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhg pdhrtghpthhtoheplhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprh gtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehlihhnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehmihhklhhoshesshiivghrvgguihdrhhhupdhrtghpthhtohepjhgrtg hksehsuhhsvgdrtgiipdhrtghpthhtohepjhhksehoiihlrggsshdrohhrgh X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Apr 2026 00:07:32 -0400 (EDT) From: NeilBrown To: Linus Torvalds , Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Trond Myklebust , Anna Schumaker , Miklos Szeredi , Amir Goldstein , Jeremy Kerr , Ard Biesheuvel Cc: linux-efi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 12/19] shmem: use d_duplicate() Date: Mon, 27 Apr 2026 14:01:30 +1000 Message-ID: <20260427040517.828226-13-neilb@ownmail.net> X-Mailer: git-send-email 2.50.0.107.gf914562f5916.dirty In-Reply-To: <20260427040517.828226-1-neilb@ownmail.net> References: <20260427040517.828226-1-neilb@ownmail.net> Reply-To: NeilBrown Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: NeilBrown To prepare for d_alloc_parallel() being permitted without a directory lock, use d_duplicate() when duplicating a dentry in order to create a whiteout. Signed-off-by: NeilBrown --- mm/shmem.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/shmem.c b/mm/shmem.c index 3b5dc21b323c..8b0d2340dee7 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -4006,11 +4006,12 @@ static int shmem_whiteout(struct mnt_idmap *idmap, struct dentry *whiteout; int error; =20 - whiteout =3D d_alloc(old_dentry->d_parent, &old_dentry->d_name); + whiteout =3D d_duplicate(old_dentry); if (!whiteout) return -ENOMEM; error =3D shmem_mknod(idmap, old_dir, whiteout, S_IFCHR | WHITEOUT_MODE, WHITEOUT_DEV); + d_lookup_done(whiteout); dput(whiteout); return error; } --=20 2.50.0.107.gf914562f5916.dirty From nobody Wed Jun 17 07:22:57 2026 Received: from fhigh-a5-smtp.messagingengine.com (fhigh-a5-smtp.messagingengine.com [103.168.172.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5E94922423A; Mon, 27 Apr 2026 04:07:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.156 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262874; cv=none; b=rtWvImG7x+qc6NHwqN600jsC5OFoPTh38Afx3Vy7+sOoiFpjznft4sJl+9gIdfKy+JZJ3wUPg4zsUsj+e3tAS6KQ5m7GEBYF/yzA3Aea2elxI/w+vrek1RpBg/Zmna35MyhnJN1tG/lWweskMdul77WxYlIC2a4VSPm22RhJW9k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262874; c=relaxed/simple; bh=R8RTr73kDdtIdtZlHNHhZGf1H97V3ZZBbREhAgyCF6g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rfpjZFaska3EvLvO3wlHBmoWRiHxLlF2+7pu3La0UzqpiyQiKpF4uEtvIz8tJivGaJJzs6+jGhFFTBP9iQL1/pIPh9XXT/eqhR42j1uosFw1No/zT1zfl8tXipxcwrcrfD6E2vXYthOuzVK7zIAzHwn4bwbbBcUBxHPRMQ9Tu3M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net; spf=pass smtp.mailfrom=ownmail.net; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b=mLLAnJTp; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=UfOtO6YK; arc=none smtp.client-ip=103.168.172.156 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ownmail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b="mLLAnJTp"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="UfOtO6YK" Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.phl.internal (Postfix) with ESMTP id B11191400046; Mon, 27 Apr 2026 00:07:52 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Mon, 27 Apr 2026 00:07:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ownmail.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to; s=fm2; t=1777262872; x=1777349272; bh=9AVqWdMXv3arOefL33JAEpcHRtNfzSlIFOE+OQc0Rdg=; b= mLLAnJTpo68d+44VmWJ2shXrZUoK7hoUmRLl+g7OhD8bETnS/CnQkwI93L6rYN+D yWlGgw6WPzXjfPmCs9XPgil811/laFKXNlgGnc+L+R5rHNOpz5CrGWqYw57sqZPU +47GycDY4yaKQQKYUtCjLHP4jesgkWX9bzt5ATL3+xc6JEiXFhFpVztuaK8gbUs/ 4LT7xSK/EgrEyQx41IAGyL8tDxeqYtFwjBXrTrU+g55NAE+Eszcagl3gklL6E+hp COW1k98qvgQwDyki1YtKyc972nxoC0TkGU28JxTHRv5ieq+GHtOSaw8zlIjiHpG1 gHCrlxOzRp5PLD6Q8Wdr6w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1777262872; x=1777349272; bh=9 AVqWdMXv3arOefL33JAEpcHRtNfzSlIFOE+OQc0Rdg=; b=UfOtO6YKp6V+6jxvu kckMHRkZGe9qWll1ZckeFe+XHZwOq7lufZX+pSRGPw/xyU7Wt1h8DdKxEoMiR7tB I4te1Bqnc9JkqMrtK/XbXdqScRl7D6KEmKPDI6kBm1XGe3MkJXKdlJaoD39G0PYk qQnTGVtFAYnQdg+2MHAfOLPPxTUY0JbFVVdzFZnISQPTiEbfP/JwqjMR0b8jqsFs F1AJEwuVUAZZ0g02pLLAlbFsBoCAYZhYSBcSj+4JWaSOWdIwPPME32lWRN9mc6Of PL4evonKRgZNoaawJtFrW3CXlbohAytmgQKfYvn48RCN7fRbrWzjssGp5DnEz67F TYkJg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdejjeeikecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffkffojghfrhgggfestdekredtredttdenucfhrhhomheppfgvihhluehr ohifnhcuoehnvghilhgssehofihnmhgrihhlrdhnvghtqeenucggtffrrghtthgvrhhnpe evveekffduueevhfeigefhgfdukedtleekjeeitdejudfgueekvdekffdvfedvudenucev lhhushhtvghrufhiiigvpeehnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhgsse hofihnmhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeduiedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvhhirhhoseiivghnihhvrdhlihhnuhigrdhorhhgrdhukhdprh gtphhtthhopehlihhnuhigqdhunhhiohhnfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhg pdhrtghpthhtoheplhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprh gtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehlihhnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehmihhklhhoshesshiivghrvgguihdrhhhupdhrtghpthhtohepjhgrtg hksehsuhhsvgdrtgiipdhrtghpthhtohepjhhksehoiihlrggsshdrohhrgh X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Apr 2026 00:07:48 -0400 (EDT) From: NeilBrown To: Linus Torvalds , Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Trond Myklebust , Anna Schumaker , Miklos Szeredi , Amir Goldstein , Jeremy Kerr , Ard Biesheuvel Cc: linux-efi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 13/19] nfs: remove d_drop()/d_alloc_parallel() from nfs_atomic_open() Date: Mon, 27 Apr 2026 14:01:31 +1000 Message-ID: <20260427040517.828226-14-neilb@ownmail.net> X-Mailer: git-send-email 2.50.0.107.gf914562f5916.dirty In-Reply-To: <20260427040517.828226-1-neilb@ownmail.net> References: <20260427040517.828226-1-neilb@ownmail.net> Reply-To: NeilBrown Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: NeilBrown It is important that two non-create NFS "open"s of a negative dentry don't race. They both have only a shared lock on i_rwsem and so could run concurrently, but they might both try to call d_splice_alias() at the same time which is confusing at best. nfs_atomic_open() currently avoids this by discarding the negative dentry and creating a new one using d_alloc_parallel(). Only one thread can successfully get the d_in_lookup() dentry, the other will wait for the first to finish, and can use the result of that first lookup. A proposed locking change inverts the order between i_rwsem and d_alloc_parallel() so it will not be safe to call d_alloc_parallel() while holding i_rwsem - even shared. We can achieve the same effect by causing ->d_revalidate to invalidate a negative dentry when LOOKUP_OPEN is set. Doing this is consistent with the "close to open" caching semantics of NFS which requires the server to be queried whenever opening a file - cached information must not be trusted. With this change to ->d_revaliate (implemented in nfs_neg_need_reval) we can be sure that we have exclusive access to any dentry that reaches nfs_atomic_open(). Either O_CREAT was requested and so the parent is locked exclusively, or the dentry will have DCACHE_PAR_LOOKUP set. This means that the d_drop() and d_alloc_parallel() calls in nfs_atomic_lookup() are no longer needed to provide exclusion Signed-off-by: NeilBrown --- fs/nfs/dir.c | 30 +++++++----------------------- 1 file changed, 7 insertions(+), 23 deletions(-) diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c index 9580af999d70..0791fc2d161b 100644 --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -1656,6 +1656,13 @@ int nfs_neg_need_reval(struct inode *dir, struct den= try *dentry, { if (flags & (LOOKUP_CREATE | LOOKUP_RENAME_TARGET)) return 0; + if (flags & LOOKUP_OPEN) + /* close-to-open semantics require we go to server + * on each open. By invalidating the dentry we + * also ensure nfs_atomic_open() always has exclusive + * access to the dentry. + */ + return 0; if (NFS_SERVER(dir)->flags & NFS_MOUNT_LOOKUP_CACHE_NONEG) return 1; /* Case insensitive server? Revalidate negative dentries */ @@ -2111,7 +2118,6 @@ int nfs_atomic_open(struct inode *dir, struct dentry = *dentry, struct inode *inode; unsigned int lookup_flags =3D 0; unsigned long dir_verifier; - bool switched =3D false; int created =3D 0; int err; =20 @@ -2156,17 +2162,6 @@ int nfs_atomic_open(struct inode *dir, struct dentry= *dentry, attr.ia_size =3D 0; } =20 - if (!(open_flags & O_CREAT) && !d_in_lookup(dentry)) { - d_drop(dentry); - switched =3D true; - dentry =3D d_alloc_parallel(dentry->d_parent, - &dentry->d_name); - if (IS_ERR(dentry)) - return PTR_ERR(dentry); - if (unlikely(!d_in_lookup(dentry))) - return finish_no_open(file, dentry); - } - ctx =3D create_nfs_open_context(dentry, open_flags, file); err =3D PTR_ERR(ctx); if (IS_ERR(ctx)) @@ -2209,10 +2204,6 @@ int nfs_atomic_open(struct inode *dir, struct dentry= *dentry, trace_nfs_atomic_open_exit(dir, ctx, open_flags, err); put_nfs_open_context(ctx); out: - if (unlikely(switched)) { - d_lookup_done(dentry); - dput(dentry); - } return err; =20 no_open: @@ -2235,13 +2226,6 @@ int nfs_atomic_open(struct inode *dir, struct dentry= *dentry, res =3D ERR_PTR(-EOPENSTALE); } } - if (switched) { - d_lookup_done(dentry); - if (!res) - res =3D dentry; - else - dput(dentry); - } return finish_no_open(file, res); } EXPORT_SYMBOL_GPL(nfs_atomic_open); --=20 2.50.0.107.gf914562f5916.dirty From nobody Wed Jun 17 07:22:57 2026 Received: from fhigh-a5-smtp.messagingengine.com (fhigh-a5-smtp.messagingengine.com [103.168.172.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7523D23EAB3; Mon, 27 Apr 2026 04:08:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.156 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262890; cv=none; b=lAEqbbqN6ja0Gjyz2I/5IkqBnvjLhW2yK4aJDgD80i97JN+LJB1hhb7wwIjgjGc+v6gdzWNzACxtb3oUtzUaX22MytRZR05duQlSdggerOXAEtsw6M7VI3QmJ0TIWwS4fM/6i2XcUW9Y1OJ4o8z/V1FuwwlMz03+mKkx8vm7bac= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262890; c=relaxed/simple; bh=JM9LLqSf9XLlCtfxMB7Z+hQXEmomGURwLcnDXDC0yHY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sHUxp7QlBG4woY/Drl12+K4Pogg+dYmvLMek/I91PstVSAtvXQ4/zvH21vBUAO7nFL4bU4pl9vJzpNiTlzqeo4sxO3yQ9gSKluuAYd/6f5Lx+tUqUHKpR2eTMTwIDp+EVkogg2lh210++blOchPTUaxnBPsSGR52ksHLagj3Lc4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net; spf=pass smtp.mailfrom=ownmail.net; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b=XW8oWgK1; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=c78zhWhA; arc=none smtp.client-ip=103.168.172.156 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ownmail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b="XW8oWgK1"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="c78zhWhA" Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.phl.internal (Postfix) with ESMTP id C112D14000B0; Mon, 27 Apr 2026 00:08:08 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Mon, 27 Apr 2026 00:08:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ownmail.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to; s=fm2; t=1777262888; x=1777349288; bh=As30Bn0VYVoxaWKi4m0aODUf1VutcCrIZEa7WHHt+uk=; b= XW8oWgK1KBqGQrsKFk9tG7WREvUEjFyiWui/Nsi0mgFW9Jn4inCszfn51AhD0bZM Lf5d7j0GEBgVCKii0Yrh9fnegRMbHH+gvyraiC/oPzbAg0sPFdCRsPZkfXmIlYGP Oyo833zp74YwCV6WUXlFfHqp1p+MAgBBCLN8ZVq9VrKVryieq7j8MkZqX2/l54SY Z8QbiWKQ+3mCcTsVOhdYDJimpMyhE0BHQSZCx0go+jaM1s1VLLo+lS6m5/bqevsM CBW6FZrmSP1vh70SAGXhZM+M4Zv5ZnZ2OnmMGqcwRDYyzW0n1anU7wkYgnFK97hr EVNr3FTVO1/454K+tAzAqA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1777262888; x=1777349288; bh=A s30Bn0VYVoxaWKi4m0aODUf1VutcCrIZEa7WHHt+uk=; b=c78zhWhAgOoFgytQY MKEDCwK6jeLoETuGUGZrrxYCw4HGzGMcJ8Cvk3bsk78Of77wiiYZi8DszoyTdYCe 0n9h1qvoxAQmxCdjZ9ESo508iyd3/hNKUV1rPLqMY9+Ryo5AbCTjCnQajqajluzZ nO73dW0PXe8EkPx/Spcy/nLI+vSdGWUC6gq+VG2Nh/6FCiWnA2WmoOSmjTCK8Luk 8FPneu/GxvN9qMPaMbrLpCZRnb12dKZx+6PnEuzZLjhz9TNHP6trrSgbsPx/lThE UDRXxCESfkf5ueAJ0PPn8HSpe10Xh6Ak/xqskOQ8BIDFjQS6P3BI2W202NN9VJ6j 8G24w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdejjeeikecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffkffojghfrhgggfestdekredtredttdenucfhrhhomheppfgvihhluehr ohifnhcuoehnvghilhgssehofihnmhgrihhlrdhnvghtqeenucggtffrrghtthgvrhhnpe evveekffduueevhfeigefhgfdukedtleekjeeitdejudfgueekvdekffdvfedvudenucev lhhushhtvghrufhiiigvpeeinecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhgsse hofihnmhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeduiedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvhhirhhoseiivghnihhvrdhlihhnuhigrdhorhhgrdhukhdprh gtphhtthhopehlihhnuhigqdhunhhiohhnfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhg pdhrtghpthhtoheplhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprh gtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehlihhnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehmihhklhhoshesshiivghrvgguihdrhhhupdhrtghpthhtohepjhgrtg hksehsuhhsvgdrtgiipdhrtghpthhtohepjhhksehoiihlrggsshdrohhrgh X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Apr 2026 00:08:04 -0400 (EDT) From: NeilBrown To: Linus Torvalds , Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Trond Myklebust , Anna Schumaker , Miklos Szeredi , Amir Goldstein , Jeremy Kerr , Ard Biesheuvel Cc: linux-efi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 14/19] nfs: use d_splice_alias() in nfs_link() Date: Mon, 27 Apr 2026 14:01:32 +1000 Message-ID: <20260427040517.828226-15-neilb@ownmail.net> X-Mailer: git-send-email 2.50.0.107.gf914562f5916.dirty In-Reply-To: <20260427040517.828226-1-neilb@ownmail.net> References: <20260427040517.828226-1-neilb@ownmail.net> Reply-To: NeilBrown Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: NeilBrown When filename_linkat() calls filename_create() which ultimately calls ->lookup, the flags LOOKUP_CREATE|LOOKUP_EXCL are passed. nfs_lookup() treats this as an exclusive create (which it is) and skips the ->lookup, leaving the dentry unchanged. Currently that means nfs_link() can get a hashed dentry (if the name was already in the cache) or an unhashed dentry (if it wasn't). As none of d_add(), d_instantiate(), d_splice_alias() could handle both of these, nfs_link() calls d_drop() and then then d_add(). Recent changes to d_splice_alias() mean that it *can* work with either hashed or unhashed dentries. Future changes to locking mean that it will be unsafe to d_drop() a dentry while an operation (in this case "link()") is still ongoing. So change to use d_splice_alias(), and not to d_drop() until an error is detected (as in that case was can't be sure what is actually on the server). Also update the comment for nfs_is_exclusive_create() to note that link(), mkdir(), mknod(), symlink() all appear as exclusive creates. Those other than link() already used d_splice_alias() via nfs_add_or_obtain(). Signed-off-by: NeilBrown --- fs/nfs/dir.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c index 0791fc2d161b..2c1315a02e52 100644 --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -1570,6 +1570,9 @@ static int nfs_check_verifier(struct inode *dir, stru= ct dentry *dentry, /* * Use intent information to check whether or not we're going to do * an O_EXCL create using this path component. + * Note that link(), mkdir(), mknod(), symlink() all appear as + * exclusive creation. Regular file creation could be distinguished + * with LOOKUP_OPEN. */ static int nfs_is_exclusive_create(struct inode *dir, unsigned int flags) { @@ -2676,14 +2679,15 @@ nfs_link(struct dentry *old_dentry, struct inode *d= ir, struct dentry *dentry) old_dentry, dentry); =20 trace_nfs_link_enter(inode, dir, dentry); - d_drop(dentry); if (S_ISREG(inode->i_mode)) nfs_sync_inode(inode); error =3D NFS_PROTO(dir)->link(inode, dir, &dentry->d_name); if (error =3D=3D 0) { nfs_set_verifier(dentry, nfs_save_change_attribute(dir)); ihold(inode); - d_add(dentry, inode); + d_splice_alias(inode, dentry); + } else { + d_drop(dentry); } trace_nfs_link_exit(inode, dir, dentry, error); return error; --=20 2.50.0.107.gf914562f5916.dirty From nobody Wed Jun 17 07:22:57 2026 Received: from fout-a8-smtp.messagingengine.com (fout-a8-smtp.messagingengine.com [103.168.172.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0244C23EAB3; Mon, 27 Apr 2026 04:08:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.151 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262905; cv=none; b=A97NGZajG3jvlpnnSDgESsvSNZpIV/eB28nFovNNus93Oq5t7SIOvMK7AJ21Eif3WTR2wlcayC0txq0hNE99h9XwSHkSGNcuiCZbh1iji/OPTuUECKGiVNh0prjm2b6DjOBwZ2D9e+FOlV9p22FaF6ZWOReC+Q77/8rgb7ziA8o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262905; c=relaxed/simple; bh=yu2CmD9YSye1yc1J/CJYEDi4OTu8Iv0aFTQqvMYN9v8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=q2rp9UDnE0c3BSQT5zlB1Rkc5lBfVG3/WFQx18N/cUpL7wmmBtXUALrzNQUG6hE6WLhggwOrLJyJa06nWf/WY8Nw63bPfvWC/sNSH2nT0ZN5RMVtUzvoDJdrRxd4IUjVLdHJ/gsa+jfr5j+KJ2RX+W5PYzNSdMjZcNFwuWJOU/Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net; spf=pass smtp.mailfrom=ownmail.net; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b=D8Bt587J; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=h5mognow; arc=none smtp.client-ip=103.168.172.151 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ownmail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b="D8Bt587J"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="h5mognow" Received: from phl-compute-07.internal (phl-compute-07.internal [10.202.2.47]) by mailfout.phl.internal (Postfix) with ESMTP id 41922EC050F; Mon, 27 Apr 2026 00:08:23 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-07.internal (MEProxy); Mon, 27 Apr 2026 00:08:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ownmail.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to; s=fm2; t=1777262903; x=1777349303; bh=eWLZ+jMmYCRM3nin9etjMLs+lfC4IZ3wcbDwBF+yVeo=; b= D8Bt587J5yweRGAJ3IT7Y+dX09t95nu8rJPS2NiYEO5o+vYyqgL0SQ/pHZd9WA5E yTLGyVABbQfgaDSs/AyjuX9eMMkLQiy3gmyStnvnMvf+u7vrlTvhI0c/KkKH9xN4 MyjA6hIoRKv1eX75P7pHV7rNhi509jt6L7hnuCVW46imr8QtQdy7mfpb+9pVi+6w Vbf165LvbJM02WzH+ssK+4NnGCD5hfAVz4PrFMDzMkO2O1Qjxb8No1bwelqeCiVy 3ri53MoPkzMXOpyesyOdtyJIZQulKS3b5yKpTAI3n1xRJ1rd++o45sdSksHEIQf3 Y4mGA9ZccU7bTbG2coGG4A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1777262903; x=1777349303; bh=e WLZ+jMmYCRM3nin9etjMLs+lfC4IZ3wcbDwBF+yVeo=; b=h5mognowTF2b4LuTg vzrCVIi84wJH4lAopCB5lfzcN25sOU2PkYN066nJrKYkBqoxk1ezkP9vdfOZ13wF WQBjST+eQuujXNm9cWWVIGR3DC/q6L5VhnyvN8GmMqi4Gvegp5nLGgXzGOvDGTi8 HozKKLTKLkIDC0ClgAuAo4G3qtyZcm/SR3kJcxYN4aniIg8U+wdacBpA+hq7R+Mt sCCynBJJNic8la9Vhjs9Cmdxk4pOc3aYghg2AGGspohqj8HnajlJ2lj0JaWrSW2N pxtzhwukr9u+gLqx1+Mp4P9LXXs7Ew0inCBhFh2A/oa9YqWp2u1QQagoPkLH1pAu 1b6Bg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdejjeeikecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffkffojghfrhgggfestdekredtredttdenucfhrhhomheppfgvihhluehr ohifnhcuoehnvghilhgssehofihnmhgrihhlrdhnvghtqeenucggtffrrghtthgvrhhnpe evveekffduueevhfeigefhgfdukedtleekjeeitdejudfgueekvdekffdvfedvudenucev lhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhgsse hofihnmhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeduiedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvhhirhhoseiivghnihhvrdhlihhnuhigrdhorhhgrdhukhdprh gtphhtthhopehlihhnuhigqdhunhhiohhnfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhg pdhrtghpthhtoheplhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprh gtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehlihhnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehmihhklhhoshesshiivghrvgguihdrhhhupdhrtghpthhtohepjhgrtg hksehsuhhsvgdrtgiipdhrtghpthhtohepjhhksehoiihlrggsshdrohhrgh X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Apr 2026 00:08:18 -0400 (EDT) From: NeilBrown To: Linus Torvalds , Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Trond Myklebust , Anna Schumaker , Miklos Szeredi , Amir Goldstein , Jeremy Kerr , Ard Biesheuvel Cc: linux-efi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 15/19] nfs: don't d_drop() before d_splice_alias() Date: Mon, 27 Apr 2026 14:01:33 +1000 Message-ID: <20260427040517.828226-16-neilb@ownmail.net> X-Mailer: git-send-email 2.50.0.107.gf914562f5916.dirty In-Reply-To: <20260427040517.828226-1-neilb@ownmail.net> References: <20260427040517.828226-1-neilb@ownmail.net> Reply-To: NeilBrown Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: NeilBrown nfs_add_or_obtain() is used, often via nfs_instantiate(), to attach a newly created inode to the appropriate dentry - or to provide an alternate dentry. It has to drop the dentry first, which is problematic for proposed locking changes. As d_splice_alias() now works with hashed dentries, the d_drop() is no longer needed. However we still d_drop() on error as the status of the name is uncertain. nfs_open_and_get_state() is only used for files so we should be able to use d_instantiate(). However as that depends on the server for correctness, it is safer to stay with the current code pattern and use d_splice_alias() there too. Signed-off-by: NeilBrown --- fs/nfs/dir.c | 3 +-- fs/nfs/nfs4proc.c | 1 - 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c index 2c1315a02e52..e1d56400fc6a 100644 --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -2329,8 +2329,6 @@ nfs_add_or_obtain(struct dentry *dentry, struct nfs_f= h *fhandle, struct dentry *d; int error; =20 - d_drop(dentry); - if (fhandle->size =3D=3D 0) { error =3D NFS_PROTO(dir)->lookup(dir, dentry, &dentry->d_name, fhandle, fattr); @@ -2351,6 +2349,7 @@ nfs_add_or_obtain(struct dentry *dentry, struct nfs_f= h *fhandle, dput(parent); return d; out_error: + d_drop(dentry); d =3D ERR_PTR(error); goto out; } diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index a9b8d482d289..185c933fb54c 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -3099,7 +3099,6 @@ static int _nfs4_open_and_get_state(struct nfs4_opend= ata *opendata, nfs_set_verifier(dentry, dir_verifier); if (d_really_is_negative(dentry)) { struct dentry *alias; - d_drop(dentry); alias =3D d_splice_alias(igrab(state->inode), dentry); /* d_splice_alias() can't fail here - it's a non-directory */ if (alias) { --=20 2.50.0.107.gf914562f5916.dirty From nobody Wed Jun 17 07:22:57 2026 Received: from fhigh-a5-smtp.messagingengine.com (fhigh-a5-smtp.messagingengine.com [103.168.172.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CED1C23ABBF; Mon, 27 Apr 2026 04:08:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.156 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262912; cv=none; b=FFlNjVmzaTBxhYHf50+SbdNfjXuMrS9tecaJg8prZRtZPTk2uIfVfbgGowK4tLriFtURcUi9pYh9o0SZ2Q2WR/kITk4t70yk7BtLLMtuv5m1VYyFaXfz7XNy+TJv4pKlfLTICmM5FOAg8TJj3SlS6CrkIToodDqd9CoksgimcFs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262912; c=relaxed/simple; bh=UdHx74w74FKyyoZPCZRo5KwN8rAmJt9dfE6PwQwR2No=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=g2qx5YgQo4xuXvqiaKnUhVeLReRA0Pp1kML8nYr2wLKIkbwyfDDZr4El3zLQRz7gpcV8KWdGfCcK6+h1TIylhKKJTO2xvtavMbc0VyqXj3kE9Ksnk9qxPV/eeAEOoU2GUBzI1H08rrLsM6pdihXG3sGjaHW7aFERA1QNlKvG3EE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net; spf=pass smtp.mailfrom=ownmail.net; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b=dmUwfLyI; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=CSuYOAL+; arc=none smtp.client-ip=103.168.172.156 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ownmail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b="dmUwfLyI"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="CSuYOAL+" Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.phl.internal (Postfix) with ESMTP id 2D15C14000D4; Mon, 27 Apr 2026 00:08:30 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Mon, 27 Apr 2026 00:08:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ownmail.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to; s=fm2; t=1777262910; x=1777349310; bh=KHyNw9Kek3PXArhCrUWi6Hbw+BW16EEF6MFx35HefNE=; b= dmUwfLyIco9/hkGiT+fR6A1e+VcjqfNe8bTgh6HVT5PdMX3aIGemgaFcqGABFAm0 EPunmabBlhyKZtAuXgbDL06vKBPwl6zoSK0k5J1mIgzp2Edca+rLCX5TypDkz4ge NH2nf2B9yBJZqgyFLRiv+RCpu4q/GLCaQkNoyawBaXHZTI04s5Mi49i909ilSzhP xoUSYRWUXA21aY6t3z9dbM44S+1VI6PLcB3INnGfwY3MScTHZJaHCLYC1/pmBFz6 5uuh7qVdE68EBLr/j1AqEN6NvgRYvol2lBzazf0BA4iETEFBc6ZsSYBUcsc4m4Nv oL+d61IbhunJuhM73vigqA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1777262910; x=1777349310; bh=K HyNw9Kek3PXArhCrUWi6Hbw+BW16EEF6MFx35HefNE=; b=CSuYOAL+yh/s9medm mNsLGeLxYCA1lVt6BFMT0+cW5FuFo+68dYh59NSreooRojh2zA3hY1tP466yoEB4 fEQ2kgWGkxFf22QRJLpy40Bte0RNXORCn/Ie3PFHANGNU27RCV8XpgElNdXHn/fV ru6q9pywO85b4AjiNOwgtQKcFhosZVa8RZ4m4XD82S4nQmPplbq5I1O4EHt2ctAL EbWxG4/hBKMo19+E4LS5xk9JE8N+XrhVQNkZhlJfN0ZxPA6WFhGjvbTifGExLhzc pMIqZ2g5vRbySKKWfILiLU9TY7sbp8E9SCr/s5hr2jXld/sgodA1P+URVcSz7fBV TfxZg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdejjeeikecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffkffojghfrhgggfestdekredtredttdenucfhrhhomheppfgvihhluehr ohifnhcuoehnvghilhgssehofihnmhgrihhlrdhnvghtqeenucggtffrrghtthgvrhhnpe evveekffduueevhfeigefhgfdukedtleekjeeitdejudfgueekvdekffdvfedvudenucev lhhushhtvghrufhiiigvpeejnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhgsse hofihnmhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeduiedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvhhirhhoseiivghnihhvrdhlihhnuhigrdhorhhgrdhukhdprh gtphhtthhopehlihhnuhigqdhunhhiohhnfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhg pdhrtghpthhtoheplhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprh gtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehlihhnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehmihhklhhoshesshiivghrvgguihdrhhhupdhrtghpthhtohepjhgrtg hksehsuhhsvgdrtgiipdhrtghpthhtohepjhhksehoiihlrggsshdrohhrgh X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Apr 2026 00:08:25 -0400 (EDT) From: NeilBrown To: Linus Torvalds , Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Trond Myklebust , Anna Schumaker , Miklos Szeredi , Amir Goldstein , Jeremy Kerr , Ard Biesheuvel Cc: linux-efi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 16/19] nfs: don't d_drop() before d_splice_alias() in atomic_create. Date: Mon, 27 Apr 2026 14:01:34 +1000 Message-ID: <20260427040517.828226-17-neilb@ownmail.net> X-Mailer: git-send-email 2.50.0.107.gf914562f5916.dirty In-Reply-To: <20260427040517.828226-1-neilb@ownmail.net> References: <20260427040517.828226-1-neilb@ownmail.net> Reply-To: NeilBrown Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: NeilBrown When atomic_create fails with -ENOENT we currently d_drop() the dentry and then re-add it (d_splice_alias()) with a NULL inode. This drop-and-re-add will not work with proposed locking changes. As d_splice_alias() now supports hashed dentries, we don't need the d_drop() until it is determined that some other error has occurred. Signed-off-by: NeilBrown --- fs/nfs/dir.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c index e1d56400fc6a..2e8389968317 100644 --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -2178,7 +2178,6 @@ int nfs_atomic_open(struct inode *dir, struct dentry = *dentry, err =3D PTR_ERR(inode); trace_nfs_atomic_open_exit(dir, ctx, open_flags, err); put_nfs_open_context(ctx); - d_drop(dentry); switch (err) { case -ENOENT: if (nfs_server_capable(dir, NFS_CAP_CASE_INSENSITIVE)) @@ -2187,7 +2186,7 @@ int nfs_atomic_open(struct inode *dir, struct dentry = *dentry, dir_verifier =3D nfs_save_change_attribute(dir); nfs_set_verifier(dentry, dir_verifier); d_splice_alias(NULL, dentry); - break; + goto out; case -EISDIR: case -ENOTDIR: goto no_open; @@ -2199,6 +2198,7 @@ int nfs_atomic_open(struct inode *dir, struct dentry = *dentry, default: break; } + d_drop(dentry); goto out; } file->f_mode |=3D FMODE_CAN_ODIRECT; --=20 2.50.0.107.gf914562f5916.dirty From nobody Wed Jun 17 07:22:57 2026 Received: from fhigh-a5-smtp.messagingengine.com (fhigh-a5-smtp.messagingengine.com [103.168.172.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C123A36EA9E; Mon, 27 Apr 2026 04:08:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.156 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262919; cv=none; b=XQ8PJm/GX24okyY4RLNoa5MW89Hri9YI7gfZxNEgp6tD1xX5zN3CMCRUlJjZmQuOH4vVcAWHD2Xlnh5p5UDMiVnXI2tKJr8sjuTclSDIHQiW/R6m8H/1IMzRkcs8FRcDRXOhG4zpQIoRaAF2K/roC0gxtrXPg9tLRItZDxFJBis= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262919; c=relaxed/simple; bh=sJ0OKrbcNy7ViG3ZtEwAeD/8P3abw5/k7zYuO3E4c2k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OWgMLFlla3rgn0G3TE584x4AW76ghmwunnEdUNn/sl2tu2EysZQrPDbL8v619AYb+huaZphw3XQmdGhNjNRfkj6KXbCNnGXG2L1NtBFYy82JAO1a/kcQ1IDQEfwmPcaxKBGwOlykaFD1x53cM922e/E3gVe7/N/ZvYcDKX/YnIo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net; spf=pass smtp.mailfrom=ownmail.net; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b=M6gre33J; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=AoUOd+0W; arc=none smtp.client-ip=103.168.172.156 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ownmail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b="M6gre33J"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="AoUOd+0W" Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfhigh.phl.internal (Postfix) with ESMTP id 3D40514000B0; Mon, 27 Apr 2026 00:08:37 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Mon, 27 Apr 2026 00:08:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ownmail.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to; s=fm2; t=1777262917; x=1777349317; bh=4j9tOzZwP5C+qc6DcPPl90vS2q7sDqXcjzpYh/ZFii8=; b= M6gre33J5RZfacJNeKaQCr+MLZwIdJiXZlsFgfxCGsp2g6A32VmusdgEBJ/fOTV3 E2Np3zmF2mcweybUZCCm7rbt60dseeebOKZonODwVl6H8siT1rDW+IwMN3SGugO0 RzeG/hDt7adgUuRSfCjAKK2eT2saPug3RjV7OtqIu6tfritBzUm8VKdxz2LQaI/R 7aMYlVd5JqU0IRWWe2OWchj9vWq0+P4hXei6iYT+ii5T5WW4GbKRWmg/aZrjMwXd Ue5i9ssWGKgxVp+ZignejbupWroIOwF79pe+klTvjDNf9sSZzT71hOB8srudlib0 t2HLB3myfbbDF//S0KXWDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1777262917; x=1777349317; bh=4 j9tOzZwP5C+qc6DcPPl90vS2q7sDqXcjzpYh/ZFii8=; b=AoUOd+0WDVDjST93d +Javtw/R6gbnHIN2svHB4YxenGRHKCkslPTh8+tY4lm5JaIeyHesOO5e0tONhKUY bNypjARVZ9geQHLO3eq1yHbWh3GUKZ0YgWXe4O1tZ/NNmKJ89s7TS2qzFll9VgYF Tfl3+iv0sUS4SAvdf2AyVdKFyNP2a9rHW1Q1Zl4xSQlt2jYMDjXOv2BUx8wX2wuS pc3UCo9HT5eyg8beQuPKbPPvlJ1Zamyz/SD6g+QVeTk2c6R96EGUpTaIaDzN2nvJ iOdTo+f9dWNiWYoyznfMHJs0HVNoyU5bSDJT4rfQQtCfojXj+3d9Q5tpgrr1QUGi 7M8OA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdejjeeilecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffkffojghfrhgggfestdekredtredttdenucfhrhhomheppfgvihhluehr ohifnhcuoehnvghilhgssehofihnmhgrihhlrdhnvghtqeenucggtffrrghtthgvrhhnpe evveekffduueevhfeigefhgfdukedtleekjeeitdejudfgueekvdekffdvfedvudenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhgsse hofihnmhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeduiedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvhhirhhoseiivghnihhvrdhlihhnuhigrdhorhhgrdhukhdprh gtphhtthhopehlihhnuhigqdhunhhiohhnfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhg pdhrtghpthhtoheplhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprh gtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehlihhnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehmihhklhhoshesshiivghrvgguihdrhhhupdhrtghpthhtohepjhgrtg hksehsuhhsvgdrtgiipdhrtghpthhtohepjhhksehoiihlrggsshdrohhrgh X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Apr 2026 00:08:32 -0400 (EDT) From: NeilBrown To: Linus Torvalds , Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Trond Myklebust , Anna Schumaker , Miklos Szeredi , Amir Goldstein , Jeremy Kerr , Ard Biesheuvel Cc: linux-efi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 17/19] nfs: Use d_alloc_noblock() in nfs_prime_dcache() Date: Mon, 27 Apr 2026 14:01:35 +1000 Message-ID: <20260427040517.828226-18-neilb@ownmail.net> X-Mailer: git-send-email 2.50.0.107.gf914562f5916.dirty In-Reply-To: <20260427040517.828226-1-neilb@ownmail.net> References: <20260427040517.828226-1-neilb@ownmail.net> Reply-To: NeilBrown Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: NeilBrown NFS uses the results of readdir to prime the dcache. Using d_alloc_parallel() can block if there is a concurrent lookup. Blocking in that case is pointless as the lookup will add info to the dcache and there is no value in the readdir waiting to see if it should add the info too. Also this call to d_alloc_parallel() is made while the parent directory is locked. A proposed change to locking will lock the parent later, after d_alloc_parallel(). This means it won't be safe to wait in d_alloc_parallel() while holding the directory lock. So change to use d_alloc_noblock(), which removes the need for calculating the hash or doing a preliminary lookup. Signed-off-by: NeilBrown --- fs/nfs/dir.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c index 2e8389968317..ee4b9b1a484f 100644 --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -749,15 +749,12 @@ void nfs_prime_dcache(struct dentry *parent, struct n= fs_entry *entry, if (filename.len =3D=3D 2 && filename.name[1] =3D=3D '.') return; } - filename.hash =3D full_name_hash(parent, filename.name, filename.len); =20 - dentry =3D d_lookup(parent, &filename); again: - if (!dentry) { - dentry =3D d_alloc_parallel(parent, &filename); - if (IS_ERR(dentry)) - return; - } + dentry =3D d_alloc_noblock(parent, &filename); + if (IS_ERR(dentry)) + return; + if (!d_in_lookup(dentry)) { /* Is there a mountpoint here? If so, just exit */ if (!nfs_fsid_equal(&NFS_SB(dentry->d_sb)->fsid, --=20 2.50.0.107.gf914562f5916.dirty From nobody Wed Jun 17 07:22:57 2026 Received: from fhigh-a5-smtp.messagingengine.com (fhigh-a5-smtp.messagingengine.com [103.168.172.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1F4B6299A84; Mon, 27 Apr 2026 04:08:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.156 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262929; cv=none; b=mMDVu3ANtbxQeVqwNK7nH1DxDZLVuXwvLPKDdnoZlJwvixgj7mkZF+8noXTKzLjdBDJFA4s4qidOR77dS7Fh0RHzI0a+uqSsiDCMmNZyRRMpsrbYEWkQryEvDirCuEmkSDUvMpW6FCmCNwo9ugbBYpSOsE2ynzC/btrX9c9j3a8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262929; c=relaxed/simple; bh=WZ7UveSYOpovothb9tiW51mp2dtPIr+PjSBgGKNYxBk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iNSyTW0as1iF6LQTusHglBtHEkAlAY4YbnqCqeVB9/PwTOR4JdBcODQjdxbeWrp2GpcHGS266ffsqLQlGNJveVO2h/zGLB2TGLrhYVGtzqF3g2EOCCSR3BOkHDVMMV9SGLKIhyHU3Z6JHjjPpcOYg7epqEBsq+4HxPNlald+ofQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net; spf=pass smtp.mailfrom=ownmail.net; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b=oWa5mUWK; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=NxE8/08Y; arc=none smtp.client-ip=103.168.172.156 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ownmail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b="oWa5mUWK"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="NxE8/08Y" Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfhigh.phl.internal (Postfix) with ESMTP id 6B0821400046; Mon, 27 Apr 2026 00:08:47 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-02.internal (MEProxy); Mon, 27 Apr 2026 00:08:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ownmail.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to; s=fm2; t=1777262927; x=1777349327; bh=qNsDUPxIIaAA/63Z6to/nWQPQowfPrhVEFZuvx5A43o=; b= oWa5mUWKus4uCYB7LTEchfd22952NNQozgTmXQOb8MiSTWEf/9AuS8lPbKniq6YL aAH2hbbGTzb6NrHjfIhxujxNdhJxnf2MpwUTNlTx3/ZY9d6fX8csgMNwXoXYKSr8 JTdiy2tuwIPQZwThyqd0sfGJI5g6t02N2PjgKf7Ga6TtLvtWGw/8qfz428srGtFO 5HoX87NCU8pKJ8ez+fCLTmt2kejaHddvmXOZYp+lkcnVrzSs1UpRBI9Y8k8meDfM evc81BS8k2Ww5n7kW+yWip51qBQnQoXDDll6N+6ptIvjJ0HG0DRfUmKI538K+tBj AE9bF5NYZCvVjjIESp3nJA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1777262927; x=1777349327; bh=q NsDUPxIIaAA/63Z6to/nWQPQowfPrhVEFZuvx5A43o=; b=NxE8/08Ya9Wio/Bwt xEty5D/IdN+tx+ObkliH7qFLwAdvkInKWSmduoN/cneOVGXO3h+IkTntdNETxKRE U/RQ/6vwUrSWdrEZr9qSi32qux11XF1aynq/d55NrnY2u1qKOdy7U4kFNMaGDCeC ggwoOuWw3uyEyJeodSrZBmeXxKekDsxcJJ6G5bSS/nm61QgErjR9bg6OmjnOKNPW el4KCxLH3sKQdZl4rtQ3Adc/kui2iA9DDH5OK8skjbxI/ccRTirL2w3aFwJcsuFE qV5S9qFdZCmUZsa+4sGEHuw/CVwZFppdBuIHL18a5+gKb0MwyxFkVfqQOuZlQpNT vcw+g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdejjeeikecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffkffojghfrhgggfestdekredtredttdenucfhrhhomheppfgvihhluehr ohifnhcuoehnvghilhgssehofihnmhgrihhlrdhnvghtqeenucggtffrrghtthgvrhhnpe evveekffduueevhfeigefhgfdukedtleekjeeitdejudfgueekvdekffdvfedvudenucev lhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhgsse hofihnmhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeduiedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvhhirhhoseiivghnihhvrdhlihhnuhigrdhorhhgrdhukhdprh gtphhtthhopehlihhnuhigqdhunhhiohhnfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhg pdhrtghpthhtoheplhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprh gtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehlihhnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehmihhklhhoshesshiivghrvgguihdrhhhupdhrtghpthhtohepjhgrtg hksehsuhhsvgdrtgiipdhrtghpthhtohepjhhksehoiihlrggsshdrohhrgh X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Apr 2026 00:08:42 -0400 (EDT) From: NeilBrown To: Linus Torvalds , Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Trond Myklebust , Anna Schumaker , Miklos Szeredi , Amir Goldstein , Jeremy Kerr , Ard Biesheuvel Cc: linux-efi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 18/19] nfs: use d_alloc_noblock() in silly-rename Date: Mon, 27 Apr 2026 14:01:36 +1000 Message-ID: <20260427040517.828226-19-neilb@ownmail.net> X-Mailer: git-send-email 2.50.0.107.gf914562f5916.dirty In-Reply-To: <20260427040517.828226-1-neilb@ownmail.net> References: <20260427040517.828226-1-neilb@ownmail.net> Reply-To: NeilBrown Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: NeilBrown Rather than performing a normal lookup (which will be awkward with future locking changes) use d_alloc_noblock() to find a dentry for an unused name, and then open-code the rest of lookup_slow() to see if it is free on the server. Signed-off-by: NeilBrown --- fs/nfs/unlink.c | 51 ++++++++++++++++++++++++++++++------------------- 1 file changed, 31 insertions(+), 20 deletions(-) diff --git a/fs/nfs/unlink.c b/fs/nfs/unlink.c index 43ea897943c0..1ac9bd2a63b2 100644 --- a/fs/nfs/unlink.c +++ b/fs/nfs/unlink.c @@ -445,7 +445,7 @@ nfs_sillyrename(struct inode *dir, struct dentry *dentr= y) static unsigned int sillycounter; unsigned char silly[SILLYNAME_LEN + 1]; unsigned long long fileid; - struct dentry *sdentry; + struct dentry *sdentry, *old; struct inode *inode =3D d_inode(dentry); struct rpc_task *task; int error =3D -EBUSY; @@ -462,26 +462,37 @@ nfs_sillyrename(struct inode *dir, struct dentry *den= try) =20 fileid =3D NFS_FILEID(d_inode(dentry)); =20 - sdentry =3D NULL; - do { +newname: + sillycounter++; + scnprintf(silly, sizeof(silly), + SILLYNAME_PREFIX "%0*llx%0*x", + SILLYNAME_FILEID_LEN, fileid, + SILLYNAME_COUNTER_LEN, sillycounter); + + dfprintk(VFS, "NFS: trying to rename %pd to %s\n", dentry, silly); + sdentry =3D d_alloc_noblock(dentry->d_parent, &QSTR(silly)); + if (sdentry =3D=3D ERR_PTR(-EWOULDBLOCK)) + /* Name currently being looked up */ + goto newname; + /* + * N.B. Better to return EBUSY here ... it could be + * dangerous to delete the file while it's in use. + */ + if (IS_ERR(sdentry)) + goto out; + if (d_is_positive(sdentry)) { dput(sdentry); - sillycounter++; - scnprintf(silly, sizeof(silly), - SILLYNAME_PREFIX "%0*llx%0*x", - SILLYNAME_FILEID_LEN, fileid, - SILLYNAME_COUNTER_LEN, sillycounter); - - dfprintk(VFS, "NFS: trying to rename %pd to %s\n", - dentry, silly); - - sdentry =3D lookup_noperm(&QSTR(silly), dentry->d_parent); - /* - * N.B. Better to return EBUSY here ... it could be - * dangerous to delete the file while it's in use. - */ - if (IS_ERR(sdentry)) - goto out; - } while (d_inode(sdentry) !=3D NULL); /* need negative lookup */ + goto newname; + } + /* This name isn't known locally - check on server */ + old =3D dir->i_op->lookup(dir, sdentry, 0); + d_lookup_done(sdentry); + if (old || d_is_positive(sdentry)) { + if (!IS_ERR(old)) + dput(old); + dput(sdentry); + goto newname; + } =20 ihold(inode); =20 --=20 2.50.0.107.gf914562f5916.dirty From nobody Wed Jun 17 07:22:57 2026 Received: from fhigh-a5-smtp.messagingengine.com (fhigh-a5-smtp.messagingengine.com [103.168.172.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CFF8427A916; Mon, 27 Apr 2026 04:09:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.156 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262945; cv=none; b=FZkbuqbOVa88QtLSqUJ2N+j3ug2lITAKHQuakcJZYtgyMcjSIT/J0fIztnCe/P6YAGqXpp+iYpiGtbTzZK82dK9TKZnJtrJnoOxrUgoWCNVVPmUzabofB0fliK38epGBHpSy/eeuRzBcSy/NwaLJVLdl9wBhItauGqHjFxBLrQU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777262945; c=relaxed/simple; bh=OZQWUCnhioPXbHh6CEr0ZrXkezJBRAJa3irRrT0VBn8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OpQ2ay7Ht5FOwbepBSiAxsh/PVPhSyqEnUlUMth/3IgbdLqD1CN83iNFKNQ7U97AIYc8TIJnEC5OnoQJ5Bsph7xhlbZYeODr8ltlatpZRq+Ys1jPM+nSt4hCsm81j2bkD24m3iKAlJSDMsGz9ZnhZK+eR9vz2cgmOlULLmthn7k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net; spf=pass smtp.mailfrom=ownmail.net; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b=Qj7F6Xm5; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=bZaVOSKj; arc=none smtp.client-ip=103.168.172.156 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ownmail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b="Qj7F6Xm5"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="bZaVOSKj" Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfhigh.phl.internal (Postfix) with ESMTP id 1919D1400046; Mon, 27 Apr 2026 00:09:03 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Mon, 27 Apr 2026 00:09:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ownmail.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to; s=fm2; t=1777262943; x=1777349343; bh=d0uUDizqtFn5TUR93S5pcu2hPzZI0J+S0qM13hNSWw4=; b= Qj7F6Xm55Vz3afo9WAApJzy6zCpM9TLM9IwdldIdQhhJX/qNYByVECsXLu/XRj/v thF1ve35Gtoz0APpDu+mKucCUzLh/ZXj0kfcqnb/YSJ6JtK4Ob2tMUPUCsyMXxwA SE5YOs0AMT9mZm8IHClG8sYzbRLaEzVnoLLWQjw3K23kJZvo6aX1s2cn19eRStj1 HrhGxKeezdRvdh6ZD11FOtDXacdwjAvLn8sNLmYQUa1GqbUpgq4pwy7VLMNs8d5h HgrDRDhfkDbG0DeJKvfQjYz/sR/Aav3Ve+Lg+TfIXTzjGkYKKgfMjKFjKtkEohKp VudarelvhhNrpnOt6Fxk0Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1777262943; x=1777349343; bh=d 0uUDizqtFn5TUR93S5pcu2hPzZI0J+S0qM13hNSWw4=; b=bZaVOSKjGXSAIodvv gXr96tNhrFlYuQmCk5SYzWOmXpzCR5jpxmOekC0DKa5P5hxk5NGJBoDT/huI81JP jcR3AFeil45vE0GdBbCNFY+WblMpz3+p0F7ekYaoHpLg3vNVo03fllDfFJvdkshq xDC1GypmhrXXrF3oI/YfHnJI76A1ZlCgjbhsB69AWZl4fvQUHDc+2aVOyw/ka1SH A/xSjkZrGJK/0/feddvX22FPWsywfsXllPZ429vi1yDHpzkQqRmADwd9d3RQHVQb r4JXxb1mk77CZ8+dZ/tC9YAZG0KoAefnNu/JXZIOJnQq/rgtkkTZXPRJBENa1TU5 +kSKg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdejjeeikecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffkffojghfrhgggfestdekredtredttdenucfhrhhomheppfgvihhluehr ohifnhcuoehnvghilhgssehofihnmhgrihhlrdhnvghtqeenucggtffrrghtthgvrhhnpe evveekffduueevhfeigefhgfdukedtleekjeeitdejudfgueekvdekffdvfedvudenucev lhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhgsse hofihnmhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeduiedpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepvhhirhhoseiivghnihhvrdhlihhnuhigrdhorhhgrdhukhdprh gtphhtthhopehlihhnuhigqdhunhhiohhnfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhg pdhrtghpthhtoheplhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprh gtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehlihhnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlhdrohhrghdp rhgtphhtthhopehmihhklhhoshesshiivghrvgguihdrhhhupdhrtghpthhtohepjhgrtg hksehsuhhsvgdrtgiipdhrtghpthhtohepjhhksehoiihlrggsshdrohhrgh X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Apr 2026 00:08:58 -0400 (EDT) From: NeilBrown To: Linus Torvalds , Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Trond Myklebust , Anna Schumaker , Miklos Szeredi , Amir Goldstein , Jeremy Kerr , Ard Biesheuvel Cc: linux-efi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 19/19] nfs: use d_duplicate() Date: Mon, 27 Apr 2026 14:01:37 +1000 Message-ID: <20260427040517.828226-20-neilb@ownmail.net> X-Mailer: git-send-email 2.50.0.107.gf914562f5916.dirty In-Reply-To: <20260427040517.828226-1-neilb@ownmail.net> References: <20260427040517.828226-1-neilb@ownmail.net> Reply-To: NeilBrown Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: NeilBrown As preparation for d_alloc_parallel() being allowed without the directory locked, use d_duplicate() to duplicate a dentry for silly rename. Signed-off-by: NeilBrown --- fs/nfs/dir.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c index ee4b9b1a484f..dd48dea8bc40 100644 --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -2778,11 +2778,9 @@ int nfs_rename(struct mnt_idmap *idmap, struct inode= *old_dir, spin_unlock(&new_dentry->d_lock); =20 /* copy the target dentry's name */ - dentry =3D d_alloc(new_dentry->d_parent, - &new_dentry->d_name); + dentry =3D d_duplicate(new_dentry); if (!dentry) goto out; - /* silly-rename the existing target ... */ err =3D nfs_sillyrename(new_dir, new_dentry); if (err) @@ -2847,8 +2845,10 @@ int nfs_rename(struct mnt_idmap *idmap, struct inode= *old_dir, nfs_dentry_handle_enoent(old_dentry); =20 /* new dentry created? */ - if (dentry) + if (dentry) { + d_lookup_done(dentry); dput(dentry); + } return error; } EXPORT_SYMBOL_GPL(nfs_rename); --=20 2.50.0.107.gf914562f5916.dirty