Linux NFS development
 help / color / mirror / Atom feed
From: Chuck Lever <cel@kernel.org>
To: Chuck Lever <cel@kernel.org>, Jeff Layton <jlayton@kernel.org>,
	 NeilBrown <neil@brown.name>,
	Olga Kornievskaia <okorniev@redhat.com>,
	 Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>
Cc: linux-nfs@vger.kernel.org
Subject: [PATCH 2/5] NFSD: Report the correct value in an OPEN response's ond_why field
Date: Thu, 08 Oct 2026 14:18:28 -0400	[thread overview]
Message-ID: <20261008-want-read-v1-2-e372262857c8@kernel.org> (raw)
In-Reply-To: <20261008-want-read-v1-0-e372262857c8@kernel.org>

Currently, when an NFS client sends an OPEN of a file with an
OPEN4_SHARE_ACCESS_WANT* bit set and NFSD grants no delegation, NFSD
sets ond_why to WND4_RESOURCE, even when a conflicting open or an
earlier recall on that file is the reason. NFSD reports WND4_RESOURCE
whether NFSD has hit its maximum delegation count or a second NFS
client has that file open.

When the server grants no delegation, the ond_why value is how a
client chooses between asking again for a delegation on that file
versus backing off.

Fixes: 0b26693c56cc ("nfsd: clean up nfs4_set_delegation")
Signed-off-by: Chuck Lever <cel@kernel.org>
---
 fs/nfsd/nfs4state.c | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 5075baac7586..46e7343e050a 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -1511,7 +1511,7 @@ nfs4_delegation_exists(struct nfs4_client *clp, struct nfs4_file *fp)
  * Return:
  *      On success: NULL if the delegation was successfully hashed.
  *
- *      On error: -EAGAIN if one was previously granted to this
+ *      On error: -EEXIST if one was previously granted to this
  *                 nfs4_client for this nfs4_file. Delegation is not hashed.
  *
  */
@@ -1527,7 +1527,7 @@ hash_delegation_locked(struct nfs4_delegation *dp, struct nfs4_file *fp)
 	lockdep_assert_held(&clp->cl_lock);
 
 	if (nfs4_delegation_exists(clp, fp))
-		return -EAGAIN;
+		return -EEXIST;
 	refcount_inc(&dp->dl_stid.sc_count);
 	dp->dl_stid.sc_type = SC_TYPE_DELEG;
 	list_add(&dp->dl_perfile, &fp->fi_delegations);
@@ -6944,7 +6944,7 @@ nfsd4_verify_deleg_dentry(struct nfsd4_open *open, struct nfs4_file *fp,
 				 &exp, &child);
 
 	if (err)
-		return -EAGAIN;
+		return -ESTALE;
 
 	exp_put(exp);
 	dput(child);
@@ -6967,7 +6967,7 @@ nfsd4_verify_setuid_write(struct nfsd4_open *open, struct nfsd_file *nf)
 
 	if ((open->op_share_access & NFS4_SHARE_ACCESS_WRITE) &&
 	    (inode->i_mode & (S_ISUID|S_ISGID)))
-		return -EAGAIN;
+		return -EPERM;
 	return 0;
 }
 
@@ -7053,7 +7053,7 @@ nfs4_set_delegation(struct nfsd4_open *open,
 	}
 
 	if (!nf)
-		return ERR_PTR(-EAGAIN);
+		return ERR_PTR(-EBADF);
 
 	/*
 	 * File delegations and associated locks cannot be recovered if the
@@ -7067,9 +7067,9 @@ nfs4_set_delegation(struct nfsd4_open *open,
 	spin_lock(&nn->deleg_lock);
 	spin_lock(&fp->fi_lock);
 	if (nfs4_delegation_exists(clp, fp))
-		status = -EAGAIN;
+		status = -EEXIST;
 	else if (nfsd4_verify_setuid_write(open, nf))
-		status = -EAGAIN;
+		status = -EPERM;
 	else if (!rcu_dereference_protected(fp->fi_deleg_file,
 					    lockdep_is_held(&fp->fi_lock))) {
 		rcu_assign_pointer(fp->fi_deleg_file, nf);
@@ -7298,8 +7298,10 @@ nfs4_open_delegation(struct svc_rqst *rqstp, struct nfsd4_open *open,
 			goto out_no_deleg;
 	}
 	dp = nfs4_set_delegation(open, &resp->cstate, stp, parent);
-	if (IS_ERR(dp))
+	if (IS_ERR(dp)) {
+		status = PTR_ERR(dp);
 		goto out_no_deleg;
+	}
 
 	memcpy(&open->op_delegate_stateid, &dp->dl_stid.sc_stateid, sizeof(dp->dl_stid.sc_stateid));
 
@@ -10687,7 +10689,7 @@ nfsd_get_dir_deleg(struct nfsd4_compound_state *cstate,
 	spin_lock(&fp->fi_lock);
 	/* existing delegation? */
 	if (nfs4_delegation_exists(clp, fp)) {
-		status = -EAGAIN;
+		status = -EEXIST;
 	} else if (!rcu_dereference_protected(fp->fi_deleg_file,
 					      lockdep_is_held(&fp->fi_lock))) {
 		rcu_assign_pointer(fp->fi_deleg_file, nfsd_file_get(nf));

-- 
2.55.0


  parent reply	other threads:[~2026-10-08 18:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-08 18:18 [PATCH 0/5] NFSD: Fixes for OPEN4_SHARE_ACCESS_WANT handling Chuck Lever
2026-10-08 18:18 ` [PATCH 1/5] NFSD: Report WND4_CANCELLED for an OPEN with WANT_CANCEL Chuck Lever
2026-10-08 18:18 ` Chuck Lever [this message]
2026-10-08 18:18 ` [PATCH 3/5] NFSD: Report WND4_CONTENTION for a recently recalled file Chuck Lever
2026-10-08 18:18 ` [PATCH 4/5] NFSD: Report unsupported delegation upgrade and downgrade Chuck Lever
2026-10-08 18:18 ` [PATCH 5/5] NFSD: Honor OPEN4_SHARE_ACCESS_WANT_READ_DELEG on a read-write OPEN Chuck Lever

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261008-want-read-v1-2-e372262857c8@kernel.org \
    --to=cel@kernel.org \
    --cc=Dai.Ngo@oracle.com \
    --cc=jlayton@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=okorniev@redhat.com \
    --cc=tom@talpey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox