From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 8EB6036D4FC for ; Fri, 12 Jun 2026 17:57:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781287069; cv=none; b=BaoIg1A8f5rDyW7/ilavYILLGrJsFwvJlM2PK8X1NC9qG9ISrQHe6kL/ekH/x+iG9UDSndr4LDA+BqjDwvIhAFkY0jl3jr6KQRr8c2F53z0zFoFWjH8hzTDmU0iqzmLlIwGRyZn7tgD6UPAOVzDFvwaUTpxsQujDCSaOP/Xu6YU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781287069; c=relaxed/simple; bh=qrUU/I/MhpwU2lCjSSmWYQDGD/pC3gZqQF1rOtHSFsU=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=W18Z+NdVxpGKsW1Jntx53NMastlDvBYsBT4JcFFsKCneGVrrl3YwViP27hbd1imAPq2K/0wKDZNtyR4o2NepiIwDqWrkzH3T7NTyYv3k39bWoLM2LpwtOI+VKKwza0/k3tloyRBksYsLkxqjdyE1zD/77dkagK/2Rqm+rFChVho= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=P9sCRa1d; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="P9sCRa1d" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D92111F00A3A; Fri, 12 Jun 2026 17:57:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781287068; bh=qKnmY94ujBnVl8xEP0bE4WWiBkQvevQ2ZRGhSM+2r0U=; h=Date:From:To:Cc:In-Reply-To:References:Subject; b=P9sCRa1dD8D0yEYkqhJC9YwX8RCtzV20dR3LeW1St+Kejq9w5u3NBPLWH+8Dtuv7N q6VovVUncCYVsoPsrYF5IC2NsREg0TECYBj8TjsUOm1w39+lNBqVtYybbLFWPSsoZE hBy8Le5T5uYZcAn6/Ukhtv5ci/HI3Nd1Mpk2NTbx4fMP+H0VLvjGF74TckoIGFCDRR R1pHxDzA/nlTybwGcgzQ7bJ4aMIdoGtOXAedJQNOhdW7cCznWWKkZC/uG1wW/pYCbH X+yLP2DPpeP9IBBolmRrgqtPHHvBiziFN9LlR5UZmQ8/G3/Xl7wkcbk2nbL/Mnm82t MVyTtcSyeSLXQ== Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfauth.phl.internal (Postfix) with ESMTP id 98EC6F40068; Fri, 12 Jun 2026 13:57:46 -0400 (EDT) Received: from phl-imap-15 ([10.202.2.104]) by phl-compute-10.internal (MEProxy); Fri, 12 Jun 2026 13:57:46 -0400 X-ME-Sender: X-ME-Proxy-Cause: dmFkZTFjhsR4D7eKIbH5F7KG4gFCzzMXBG+6vWiNR8RCCciXzIdB0iYrNrtbPAAw3gED1O ki4/jGbxobZu0jlK+o9n0hLjRt53QEVNvSl6NOd5GeRbSZQ6SpvUnpFVJ+D1/0ZITLg1My qD8Ufs/dZKoELWqiS1JWDcWVrk6vkyGOBVTngQwHVMGnNjr2yTX12mw+hCAmMVSVFJtuV6 bMPYkZgszBkoVGxvqE8Z07VX4HvVyFTEwIJsMN31UvXy2mzI19ikRnPz2zqh2jtLiECqhg ZA+x9RPDastAOTAXj5wJhdSZAbw/wBp/uJBImNj8ugXRihM7V4OE3+KdPirA3R6hsFxTqA jSr8O6LNVSPVPHo0VpqP6LaISjfwsvLcUIZOrSUWiJw7B7GIE9b+gBNyuRtztS5+gfTFzE 84ArQIj/5ua/lpyAr9mKBwz7NSXgUSAL2og545qH42SQi2PjdfbVklGoqtInrLEzksnbxu IqD6xmo3LbQqvlcK7xYgcQqDWRUTh2LiWPsKvulthZKu8HCbq46stuaIxCm43fhNnLERcy C15+BWPGG7ZHw5NJbgYvzKFNg+mRAzeECiVwyBpSbcOjcA1SAOqmZ1dTnJDlmwvlxYmN6H LpJBvoeOt0ca2dyg7Q8yjkfB1LFcv8kEDzJon3xrqVg9bhwZgwchCPc00irw X-ME-Proxy: Feedback-ID: ifa6e4810:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 7408F780070; Fri, 12 Jun 2026 13:57:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: AqANW_W8EHC7 Date: Fri, 12 Jun 2026 13:57:26 -0400 From: "Chuck Lever" To: "Jeff Layton" , NeilBrown , "Olga Kornievskaia" , "Dai Ngo" , "Tom Talpey" , "Trond Myklebust" , "Anna Schumaker" , "Jonathan Corbet" , "Shuah Khan" Cc: "Steven Rostedt" , "Alexander Aring" , "Amir Goldstein" , "Jan Kara" , "Alexander Viro" , "Christian Brauner" , "Calum Mackay" , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-nfs@vger.kernel.org Message-Id: In-Reply-To: <20260611-dir-deleg-v6-11-4c45080e5f3f@kernel.org> References: <20260611-dir-deleg-v6-0-4c45080e5f3f@kernel.org> <20260611-dir-deleg-v6-11-4c45080e5f3f@kernel.org> Subject: Re: [PATCH v6 11/20] nfsd: apply the notify mask to the delegation when requested Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, Jun 11, 2026, at 1:50 PM, Jeff Layton wrote: > If the client requests a directory delegation with notifications > enabled, set the appropriate return mask in gddr_notification[0]. This > will ensure the lease acquisition sets the appropriate ignore mask. > > If the client doesn't set NOTIFY4_GFLAG_EXTEND, then don't offer any > notifications, as nfsd won't provide directory offset information, and > "classic" notifications require them. > > Signed-off-by: Jeff Layton > --- > fs/nfsd/nfs4proc.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c > index 0c37d7c6d28c..29f7339dc220 100644 > --- a/fs/nfsd/nfs4proc.c > +++ b/fs/nfsd/nfs4proc.c > @@ -2530,12 +2530,18 @@ nfsd4_verify(struct svc_rqst *rqstp, struct > nfsd4_compound_state *cstate, > return status == nfserr_same ? nfs_ok : status; > } > > +#define SUPPORTED_NOTIFY_MASK (BIT(NOTIFY4_REMOVE_ENTRY) | \ > + BIT(NOTIFY4_ADD_ENTRY) | \ > + BIT(NOTIFY4_RENAME_ENTRY) | \ > + BIT(NOTIFY4_GFLAG_EXTEND)) > + > static __be32 > nfsd4_get_dir_delegation(struct svc_rqst *rqstp, > struct nfsd4_compound_state *cstate, > union nfsd4_op_u *u) > { > struct nfsd4_get_dir_delegation *gdd = &u->get_dir_delegation; > + u32 requested = gdd->gdda_notification_types[0]; > struct nfs4_delegation *dd; > struct nfsd_file *nf; > __be32 status; > @@ -2544,6 +2550,12 @@ nfsd4_get_dir_delegation(struct svc_rqst *rqstp, > if (status != nfs_ok) > return status; > > + /* No notifications if you don't set NOTIFY4_GFLAG_EXTEND! */ > + if (!(requested & BIT(NOTIFY4_GFLAG_EXTEND))) > + requested = 0; > + > + gdd->gddr_notification[0] = requested & SUPPORTED_NOTIFY_MASK; > + > /* > * RFC 8881, section 18.39.3 says: > * > When a client requests NOTIFY4_GFLAG_EXTEND | NOTIFY4_CFLAG_ORDER plus ADD/REMOVE/RENAME, the assignment still grants the content notification bits because it only requires GFLAG_EXTEND. The rest of NFSD's CB_NOTIFY encoder does not store that order-aware request and emits zero/absent cookie and previous-entry information, which is only safe for order-unaware clients. An order-aware client can then keep an ordered directory cache from unusable notifications instead of having the delegation recalled. The bis draft requires order info for order-aware clients, or recall: - 27.4.5 (REMOVE): "If the client is order-aware, the server will send the cookie value as part of this." - 16.2.13: order-aware == NOTIFY4_CFLAG_ORDER set OR NOTIFY4_GFLAG_EXTEND reset. - 16.2.11.3: "If the client is concerned with entry order and these notifications ... cannot be sent for any other reason, then the delegation is recalled." This patch's own first rule (drop everything when GFLAG_EXTEND is reset) is exactly the order-aware -> no-notifications principle for legacy RFC8881 clients. It misses the parallel case: GFLAG_EXTEND set PLUS CFLAG_ORDER set is also order-aware. This finding is latent when this patch is first applied, but the NFSD's negotiation is incorrect for any future order-aware client. I don't see this issue addressed by a subsequent patch in this series. -- Chuck Lever