From: Roberto Bergantinos Corpas <rbergant@redhat.com>
To: trondmy@kernel.org, anna@kernel.org
Cc: neil@brown.name, prabhakar.pujeri@dell.com, linux-nfs@vger.kernel.org
Subject: [PATCH v2] NFS: return DENIED in decode_lock_denied if we cannot decode owner
Date: Thu, 17 Sep 2026 12:49:05 +0200 [thread overview]
Message-ID: <20260917104905.669983-1-rbergant@redhat.com> (raw)
After commit 43502f6e8d1e ("NFS: fix open_owner_id_maxsz and related
fields.") we dramatically changed the size of the LOCK/LOCKT reply buffer
from 164 to 52 bytes. This made visible a situation on a buggy NFS
server that sent oversized denied responses which led to us returning
EIO instead of DENIED.
Now, apart from buggy server issue, this poses an interesting question:
what if other implementations have legitimate but bigger than we expect
lock owner response, especially now that we have reduced the size we
allocate for it (20 bytes for the lock owner part).
This change proposes to tackle that issue returning DENIED instead of
EIO regardless of whether we manage to decode the owner or not:
- At this point of decode_lock_denied we know there is an owner.
- Server legitimately denied the lock request, with an owner that fits on
NFS4_OPAQUE_LIMIT but we returned EIO instead to userspace.
- The owner data is decoded but actually never used, decode_lock path
simply retries, and decode_lockt turns it into 0 on file_lock and
returns it to userspace.
- LOCK/LOCKT are the last operations on the compound so it's not relevant
if we didn't advance the pointer.
- Also removes an inverted likely(!p) hint.
Fixes: 43502f6e8d1e ("NFS: fix open_owner_id_maxsz and related fields.")
Signed-off-by: Roberto Bergantinos Corpas <rbergant@redhat.com>
Reviewed-by: Prabhakar Pujeri <prabhakar.pujeri@dell.com>
---
v2:
- fixed formatting issues
fs/nfs/nfs4xdr.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c
index fc049ce4ba8a..9d0f7ad7525a 100644
--- a/fs/nfs/nfs4xdr.c
+++ b/fs/nfs/nfs4xdr.c
@@ -5169,8 +5169,7 @@ static int decode_lock_denied(struct xdr_stream *xdr, struct file_lock *fl)
p = xdr_decode_hyper(p, &clientid); /* read 8 bytes */
namelen = be32_to_cpup(p); /* read 4 bytes */ /* have read all 32 bytes now */
p = xdr_inline_decode(xdr, namelen); /* variable size field */
- if (likely(!p))
- return -EIO;
+ /* We have an owner here, return DENIED */
return -NFS4ERR_DENIED;
}
--
2.45.0
next reply other threads:[~2026-09-17 10:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 10:49 Roberto Bergantinos Corpas [this message]
2026-09-17 12:24 ` [PATCH v2] NFS: return DENIED in decode_lock_denied if we cannot decode owner Jeff Layton
2026-09-25 18:01 ` Frank Filz
2026-09-24 9:15 ` Tomas Dabasinskas
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=20260917104905.669983-1-rbergant@redhat.com \
--to=rbergant@redhat.com \
--cc=anna@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--cc=prabhakar.pujeri@dell.com \
--cc=trondmy@kernel.org \
/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