On Tue, 2025-06-10 at 09:50 -0400, Chuck Lever wrote:

On 6/10/25 9:41 AM, Dai Ngo wrote:

quoted

When the client sends an OPEN with claim type CLAIM_DELEG_CUR_FH or
CLAIM_DELEGATION_CUR, the delegation stateid and the file handle
must belongs to the same file, otherwise return NFS4ERR_BAD_STATEID.

Signed-off-by: Dai Ngo <dai.ngo@oracle.com>
---
 fs/nfsd/nfs4state.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 59a693f22452..be2ee641a22d 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c

@@ -6318,6 +6318,11 @@ nfsd4_process_open2(struct svc_rqst *rqstp, struct svc_fh *current_fh, struct nf
 		status = nfs4_check_deleg(cl, open, &dp);
 		if (status)
 			goto out;
+		if (dp && nfsd4_is_deleg_cur(open) &&
+				(dp->dl_stid.sc_file != fp)) {
+			status = nfserr_bad_stateid;

How does the client react to NFS4ERR_BAD_STATEID ? Does it retry the
same request or does it reflect the failure to the application?

I imagine this triggers the client to go into state recovery, which
won't be terribly helpful. Another reason to consider a different error
code. I suggest:

    15.1.1.4. NFS4ERR_INVAL (Error Code 22)

    The arguments for this operation are not valid for some reason, even though they do match those specified in the XDR definition for the request.

This might bubble up as an application error and get noticed that way.

quoted

+			goto out;
+		}
 		stp = nfsd4_find_and_lock_existing_open(fp, open);
 	} else {
 		open->op_file = NULL;

-- 
Jeff Layton [off-list ref]