From nobody Tue Apr 7 16:16:38 2026 Received: from flow-b6-smtp.messagingengine.com (flow-b6-smtp.messagingengine.com [202.12.124.141]) (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 741B83AB290; Thu, 12 Mar 2026 21:47:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.141 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773352025; cv=none; b=AiHdKlFcgFpHiJn5Riv3lIMPrWpyAeXkDOPFI/ymfd53g7kAP9r5EpiNjsgEwQa48FUm+b8Xuk5NeILc983pdX+T2LvoSxN7eg1Dx1gXJISlp8UbWo1Xel+QUTRByen5zFq3z3zUm4Xx8cXVe2TfTsZPaD68sjnjcFnT3eTuWo4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773352025; c=relaxed/simple; bh=8EFW4rG6MnNKfSYvHr+5gwbSRTR3ykiIKyTe8AdjEDY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IMK7oq8b28Y+ii2PkFHvi+zAPlC3miOwjsCTIEIkVSsw7BpjsYfnXIlUYUaM3eqTriIMZwO74QT88Dh4mFA7owOguqSVI0xeadXun3/TU34ozmYcHIDzjY7U7fL2rsxk7iVKWLfbjSCOCgZ45NmN8h02aFLP3VLzNBdXFl0i58A= 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=BC76xmpQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=DCxT41qh; arc=none smtp.client-ip=202.12.124.141 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="BC76xmpQ"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="DCxT41qh" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailflow.stl.internal (Postfix) with ESMTP id 6586A1301B5F; Thu, 12 Mar 2026 17:47:01 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Thu, 12 Mar 2026 17:47:02 -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=fm1; t=1773352021; x=1773359221; bh=d9RhJ2BuLywXUJ/fvnCHaZYNU2thzEny+uIpuniq6ls=; b= BC76xmpQzBJ/5FWzgYwZ3exEB8Y9YxPHLjPvprCTetgklTOlLNdancD8t5ymMjZa 3NCix1LQtbhZKIJmxEJsx5VOEAsW8ee1C/VOGvYvKaDXzSQ7qm1PJWuggVq+7sOX RwRQfVuH121ZKNqX5D/PIfCsH/R6iyJhKA8S1o7+T0+6YM48RxlHwDogpHijdGHt SS6wqZBT0lkrQfBq4MLO1x3tvt0osH1t+pfpDHUUXYF4La5ohqB0DxS7k64FuKq4 /2t1hr7mfNYFsZZJGtj09uj4rOGEZYTnz7ENVdeRFWwkjiYo7XhaQ7N6ktWdp3BC HDT8R38jU0q4FXwFBawbLw== 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=fm1; t=1773352021; x=1773359221; bh=d 9RhJ2BuLywXUJ/fvnCHaZYNU2thzEny+uIpuniq6ls=; b=DCxT41qhRsolTCr8S fmLfxVTn2usDZk1YalfS014uow6ZmLtFeCiClbu0uY1EqfEce3yq0r6X15MS9F9O f5KaXSo+ceu5kK+S14baxhrU7tWh8UL4DUJ+ZQfKlkyWEz7zM0VrHY42SKCSlbIk z+JPxA1n9EmcTefXq5hlS4p7dFYZ5qD2phNVpZqECjx0aLzOZWjwX/Je2vdTQJeE cDuagD/6uB7HJqWOXrwp3hGm29I2LG09xT8ITuzo532E7DZV63YmHP8I6C6p3yMQ qGGHEUDjoK0CXP0n28Zz3w6DZ6cRwngVDUDiVADWPhnRp98AFT0MsQ5OH3LvviFd CNZRg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvkeejledtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhephffvvefufffkofgjfhhrggfgsedtkeertdertddtnecuhfhrohhmpefpvghilheu rhhofihnuceonhgvihhlsgesohifnhhmrghilhdrnhgvtheqnecuggftrfgrthhtvghrnh epveevkeffudeuvefhieeghffgudektdelkeejiedtjedugfeukedvkeffvdefvddunecu vehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhlsg esohifnhhmrghilhdrnhgvthdpnhgspghrtghpthhtohephedupdhmohguvgepshhmthhp ohhuthdprhgtphhtthhopehvihhrohesiigvnhhivhdrlhhinhhugidrohhrghdruhhkpd hrtghpthhtoheplhhinhhugidqgihfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgt phhtthhopehlihhnuhigqdhunhhiohhnfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhgpd hrtghpthhtoheplhhinhhugidqthhrrggtvgdqkhgvrhhnvghlsehvghgvrhdrkhgvrhhn vghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlh drohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgv lhdrohhrghdprhgtphhtthhopehlihhnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrh hnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqvgigthegsehvghgvrhdrkhgvrhhn vghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlh drohhrgh X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 12 Mar 2026 17:46:47 -0400 (EDT) From: NeilBrown To: Linus Torvalds , Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Trond Myklebust , Anna Schumaker , Carlos Maiolino , Miklos Szeredi , Amir Goldstein , Jan Harkes , Hugh Dickins , Baolin Wang , David Howells , Marc Dionne , Steve French , Namjae Jeon , Sungjong Seo , Yuezhang Mo , Andreas Hindborg , Breno Leitao , "Theodore Ts'o" , Andreas Dilger , Steven Rostedt , Masami Hiramatsu , Ilya Dryomov , Alex Markuze , Viacheslav Dubeyko , Tyler Hicks , Andreas Gruenbacher , Richard Weinberger , Anton Ivanov , Johannes Berg , Jeremy Kerr , Ard Biesheuvel Cc: linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-xfs@vger.kernel.org, linux-unionfs@vger.kernel.org, coda@cs.cmu.edu, linux-mm@kvack.org, linux-afs@lists.infradead.org, linux-cifs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, ceph-devel@vger.kernel.org, ecryptfs@vger.kernel.org, gfs2@lists.linux.dev, linux-um@lists.infradead.org, linux-efi@vger.kernel.org Subject: [PATCH 09/53] nfs: remove d_drop()/d_alloc_parallel() from nfs_atomic_open() Date: Fri, 13 Mar 2026 08:11:56 +1100 Message-ID: <20260312214330.3885211-10-neilb@ownmail.net> X-Mailer: git-send-email 2.50.0.107.gf914562f5916.dirty In-Reply-To: <20260312214330.3885211-1-neilb@ownmail.net> References: <20260312214330.3885211-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 52e7656195ec..3033cc5ce12f 100644 --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -1657,6 +1657,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 */ @@ -2112,7 +2119,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 @@ -2157,17 +2163,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)) @@ -2210,10 +2205,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: @@ -2236,13 +2227,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