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
next prev 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