From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=202.12.124.159 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793160645; b=SJjkE14lF73SclfFKygg+gCfy8w6ZiIrSRo2yNknUiP10dignlfwzcyELqBz8zuEkZLx duebLmQ7wD3d1x0nKk7irdcMg1ew8kHkapXBtYVOmzfXSp2Ww8pvs9n26ruMtd7Z3+CT8 UXyke4aYvzBTRZHdf5gVYfi78bVAPEl4rpbqIAWZKM/7qleiYaAWXcC0YO5dZRV1pcUlf kLYq898BC2dVd9eb9Srk50sckfhIwmwg4cj24ci3/F+VH4wvCHc6pF57IbQjz9SKyxFuD nMHH69E5Dn0uOcrZD9cL9oeg1oq5v5yQNj/JtHlcf+UHFpMZGINOam6IifefMwVb2/w== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793160645; h=DMARC-Filter:Received:Received:DKIM-Signature:DKIM-Signature: X-DKIM2-Info:DKIM2-Signature:X-DKIM2-Info:Message-Instance: X-ME-Sender:X-ME-Received:X-ME-Proxy-Cause:X-ME-Proxy:Feedback-ID: Received:From:To:Cc:Subject:Date:Message-ID:X-Mailer:In-Reply-To: References:Reply-To:MIME-Version:Content-Transfer-Encoding; bh=Y3uTHeELfmEEyxUtIyaOaiTRg7+t2a83seqf007/wrA=; b=4Iz3a7e+7atBqL5ZAuMBJgIlD1TNLkHAv+ezB1KXe1PwkGmbVFNqNpXQgoDImT3Bxj7W pXpk95HUDsB0A/HqUVW3P8yrfTM/AyzKtC9iRQlvLpW6exmCmMzvJxeaVWK6VEt71W72V 4mfBKZC8eoshN4EelV84UuZwA4nWdOo0AV9t8upojIwj+IcuYf9raHBoBThwQXtRV6iXu l8aDd8gMnsX4HarUOMPjPkbB9i1MitoY9CrTDBTi2l1MW83Az6TVCB/cJFPGedMOPwdp0 0mrePnNUnyfwdVLOwZhLZ+VYr1sQfpyI+wDguKff5gE+4VJXHDfazsoOe3ikjyP+bkA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=ownmail.net; spf=pass smtp.mailfrom=ownmail.net; dkim=pass header.d=ownmail.net header.i=@ownmail.net header.a=rsa-sha256 header.s=fm2 header.b=AwQJOLQ1; dkim=pass header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm2 header.b=hRHha2Ju; arc=none smtp.remote-ip=202.12.124.159 Received: from fhigh-b8-smtp.messagingengine.com (fhigh-b8-smtp.messagingengine.com [202.12.124.159]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4E619606A321 for ; Wed, 28 Oct 2026 04:10:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 4E619606A321 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, unprotected) header.d=ownmail.net header.i=@ownmail.net header.a=rsa-sha256 header.s=fm2 header.b=AwQJOLQ1; dkim=pass (2048-bit key, unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm2 header.b=hRHha2Ju Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfhigh.stl.internal (Postfix) with ESMTP id AF3F87A0220 for ; Wed, 28 Oct 2026 00:10:43 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-03.internal (MEProxy); Wed, 28 Oct 2026 00:10:43 -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=1793160643; x=1793247043; bh=Y3uTHeELfmEEyxUtIyaOaiTRg7+t2a83seqf007/wrA=; b= AwQJOLQ1WADWT/VFoRerR8wgWkoji12REGG9gf3QPXReN6YxhPorgHcorgPiXeEG SYBaKhzdDPYiN/8Rt0tFmEPfIVXT43HX1fp0pW2qYNLsUZ7oqcDvzE8AkZhfHor0 AEbJEdNEiv4fMOoUugWUV4LMhQfFxQa2FLaj/VojE15wVQuunlRitSqEwNVtMPvz WsG6P1md9oWARBrFgzyO1jvaS4eg8js7Y7ezbzBRPSlvm7NE9+CA63lCucC4bYsE /E+6KRetqPBN8BVmuf3do4Qi+0GkdEvBHmGxIsZ8AsFx0DNvb0rM+x689tgGC++W uOlPhF1uZwBhC9NHFmdtMg== 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=1793160643; x=1793247043; bh=Y 3uTHeELfmEEyxUtIyaOaiTRg7+t2a83seqf007/wrA=; b=hRHha2JurfjS64Hwp gDIf65evuOdq7TVkXdZM0LSBAih72/kMa7dffHlKoAy0DzBVrYC6rihJdJ8m0RYV 8rupE2+qq1O76W6Nc9w0YjdnaIq5IHbxvRUVtihBzR3qlrCilVeD/lkbqhA/jW2d HW/nZ3UMqW13tmlua/Ex8SUKTuKD6PjnO5dgVXpZkkFfo0VquCH3QK2xFyaUJaVh ZWW50tgWk+djSagK4eMxgAQSBa8QvSHsSMjDmEPI8X8ZDiO0L3fYB7V5cDzMQhbp IPDYo/Xpj8xO2sPHl2Db72BNqeiNrfvzRJQjuaRbetWl90WFunfg8CCmH9W7M9km B1tfg== X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-07; repo=github.com/dkim2wg/interop; date=2026-10-18; sw=lmtpprox; action=sign d=ownmail.net a=rsa-sha256; DKIM2-Signature: i=1; m=1; t=1793160643; d=ownmail.net; mf=PG5laWxiQG93bm1haWwubmV0Pg==; rt=PGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc+; s=fm2:rsa-sha256:SM9E3CmTfsmehvdxgQf8VTBj2nYOQ9670zRee5NwJ0ZtWcB Z+nhLEJAuOO4MQT92pl01shBObQOqY00sbuZATOzkQejtuMycZXV0CpnzDL1PRYY JjRy3YmEShVL5CH9YFWC5FW7gkAM1KFPgYHhAsyoDltit6wexmXAyOcJrNFM5zd8 Y/k5/WdFR/dSq2SFyNh43LbD702VNlGeU8dQ36a3TdSgVWdmQopxE3ui8XQn6hNz mEXhcbSajbVQCxD1Zd+tjO9yWmx945yfC4H/C3uJE4CpybMTjyZLSHuR3Czy2ACL 2X92MHWTU3MLGtErGJxDpc+75q827mK79/i4EiA==; X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-07; repo=github.com/dkim2wg/interop; date=2026-10-18; sw=lmtpprox; action=mi-m=1; hc=12; hn=cc,content-transfer-encoding,date,feedback-id,from, in-reply-to,message-id,mime-version,references,reply-to,subject, to; Message-Instance: m=1; h=sha256:a8lBIkhsNkGZnCMiKnyCKxX7HXl107xmkb5JWFwq3RE=:hdy4vVL6Dcacd7LdlML9+QzZ09PdhEBSAocGk8N+TjQ=; X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEESuysg19QF5b+660O2kFH0wKKizaiDq3tL+wvPclS+C8LEKJrd0tluZw5E2TZSD jKO9sWy5qM1Z6RrGJOlnClptCGmLXnL8kr0BiUUfd8ZtNXetU1ZWPXKVCBWZTvTl8HQQo5 /kAgRZOJdjKe/MQv1vcFnZnzhn10jhcem6LHZbsclxG8eyQgYrNc55VTrbz9X+HTxDUm4m B6LqABm2aSY8fu8glneU+PdVL/YUAUOifiQSXQ92gWSLRa7ZF2Vqmil0JAK7zOgQrMzr25 9+cCJpeSTLM9XFo3wBG6SBUEdoWgjjcPvKlhu+qxZ2GU1rSvE0IvGwv5eMEcZP3B/KpvZM NMpkfUqON+pAP9VhyxoVvRunT1q56/WEotrWgcF5U/uRspXGp66y1lSSnZcx/XovUBsF7I uDIyITB65QRn1Y63bzcGUCnojc0MltHhcq6RKSSM5kVM1cv9FoKrfkzDzR4+DT3s0KD2rk i5oZV/KJAlZL5RsahipxqAXmDtnVovvqQzJiRhvrML+KnDYm51+6aivs+YfGpe8FZT6W6m uFA7uYPtTlbVb4OJrsxr+I4FAswMIun+BQISpDxWJM8vP8AhYsKyCvBuFcpDdnhl7AuJpb dNJrZ0O6KdxXYrKBupnGkTRX4KqbmT5xydDIPXutWa0XlAJ+g+XdDOCSg2eQ X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 28 Oct 2026 00:10:39 -0400 (EDT) From: NeilBrown To: Trond Myklebust , Anna Schumaker , Alexander Viro , Christian Brauner , Jonathan Flynn Cc: Jeff Layton , Jan Kara , linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v4 1/9] nfs: fix open-blocking with d_fsdata Date: Wed, 28 Oct 2026 15:06:29 +1100 Message-ID: <20261028041023.3738553-2-neilb@ownmail.net> X-Mailer: git-send-email 2.50.0.107.gf914562f5916.dirty In-Reply-To: <20261028041023.3738553-1-neilb@ownmail.net> References: <20261028041023.3738553-1-neilb@ownmail.net> Reply-To: NeilBrown X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: NeilBrown The logic described in block_revalidate() that ->d_lock must be taken in lookup_open() missed the fact that sometimes lookup_open() isn't called. If open_last_lookups() is called while still in RCU-walk and lookup_fast() finds a dentry, it does not take ->d_lock or increment d_count() before calling d_revalidate() - only afterwards. So on that path d_count() can be incremented and the file opened *after* nfs_unlink() has checked d_count() and set NFS_FSDATA_BLOCKED. So an application could have the file open when it is unlinked on the server. To fix this we need block_revalidate() to ensure the RCU-walk path is blocked as well. This is easily done with write_seqcount_invalidate(&dentry->d_seq); legitimize_path() will increment d_count() and then check d_seq. The write_seqcount_invalidate() call will cause that check to fail if nfs_unlink() has already seen d_count() being only 1. So the RCU-walk will fail with -ECHILD and it will be retried as a ref-walk. This requires that ->d_fsdata is loaded *after* read_seqcount_begin() loaded ->d_seq, so the smp_load_acquire() in __nfs_lookup_revalidate() is important. Acked-by: Anna Schumaker Co-developed-by: Jonathan Flynn Signed-off-by: Jonathan Flynn Fixes: 99bc9f2eb3f7 ("NFS: add barriers when testing for NFS_FSDATA_BLOCKED") Signed-off-by: NeilBrown --- fs/nfs/dir.c | 30 ++++++++++++++++++++++++------ 1 file changed, 24 insertions(+), 6 deletions(-) diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c index 354f986e60c4..cde963e2bcb8 100644 --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -1835,7 +1835,11 @@ __nfs_lookup_revalidate(struct dentry *dentry, unsigned int flags) if (dentry->d_fsdata == NFS_FSDATA_BLOCKED) return -ECHILD; } else { - /* Wait for unlink to complete - see unblock_revalidate() */ + /* Wait for unlink to complete - see unblock_revalidate(). + * smp_load_acquire() ensures ->d_fsdata is read after + * ->d_seq was read, matching block_revalidate() which + * sets ->d_fsdata before ->d_seq. + */ wait_var_event(&dentry->d_fsdata, smp_load_acquire(&dentry->d_fsdata) != NFS_FSDATA_BLOCKED); @@ -1856,15 +1860,29 @@ static void block_revalidate(struct dentry *dentry) /* old devname - just in case */ kfree(dentry->d_fsdata); + dentry->d_fsdata = NFS_FSDATA_BLOCKED; + /* Any new reference that could lead to an open - * will take ->d_lock in lookup_open() -> d_lookup(). - * Holding this lock ensures we cannot race with - * __nfs_lookup_revalidate() and removes and need - * for further barriers. + * will either: + * - take ->d_lock in lookup_open() -> d_lookup() or + * - will check d_seq in legitimize_path() or similar + * after taking the reference. + * + * Holding this lock and invalidating ->d_seq *after* recording + * NFS_FSDATA_BLOCKED ensures we cannot race with + * __nfs_lookup_revalidate(). + * If __nfs_lookup_revalidate() doesn't see NFS_FSDATA_BLOCKED then: + * In the ref-walk case - d_lookup() will have incremented + * d_count() before we check it. + * In the RCU-walk case - ->d_seq must have been sampled before + * we call write_seqcount_invalidate() below (because it was sampled + * before we set NFS_FSDATA_BLOCKED) so d_count() will have been + * incremented or the d_seq check will fail in legitimize_path() + * (or both). */ lockdep_assert_held(&dentry->d_lock); + write_seqcount_invalidate(&dentry->d_seq); - dentry->d_fsdata = NFS_FSDATA_BLOCKED; } static void unblock_revalidate(struct dentry *dentry) base-commit: 864c07de0c7dcbca58b61625dfa2e461ae63b242 -- 2.50.0.107.gf914562f5916.dirty