Re: [PATCH v6 11/20] nfsd: apply the notify mask to the delegation when requested

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 <[email protected]>
> ---
>  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