Update error codes in decoding functions of block and scsi layout
drivers to match the core nfsd code. NFS4ERR_EINVAL means that the
server was able to decode the request, but the decoded values are
invalid. Use NFS4ERR_BADXDR instead to indicate a decoding error.
And ENOMEM is changed to nfs code NFS4ERR_DELAY.

Signed-off-by: Sergey Bashirov <sergeybashirov@gmail.com>
---
Changes in v2:
 - Add kdoc comments
 - Add return code handling to blocklayout.c

 fs/nfsd/blocklayout.c    |  4 +--
 fs/nfsd/blocklayoutxdr.c | 55 +++++++++++++++++++++++++++++++++-------
 2 files changed, 48 insertions(+), 11 deletions(-)

diff --git a/fs/nfsd/blocklayout.c b/fs/nfsd/blocklayout.c
index 08a20e5bcf7f..c3491edb0302 100644
--- a/fs/nfsd/blocklayout.c
+++ b/fs/nfsd/blocklayout.c
@@ -182,7 +182,7 @@ nfsd4_block_proc_layoutcommit(struct inode *inode,
 	nr_iomaps = nfsd4_block_decode_layoutupdate(lcp->lc_up_layout,
 			lcp->lc_up_len, &iomaps, i_blocksize(inode));
 	if (nr_iomaps < 0)
-		return nfserrno(nr_iomaps);
+		return cpu_to_be32(-nr_iomaps);
 
 	return nfsd4_block_commit_blocks(inode, lcp, iomaps, nr_iomaps);
 }
@@ -320,7 +320,7 @@ nfsd4_scsi_proc_layoutcommit(struct inode *inode,
 	nr_iomaps = nfsd4_scsi_decode_layoutupdate(lcp->lc_up_layout,
 			lcp->lc_up_len, &iomaps, i_blocksize(inode));
 	if (nr_iomaps < 0)
-		return nfserrno(nr_iomaps);
+		return cpu_to_be32(-nr_iomaps);
 
 	return nfsd4_block_commit_blocks(inode, lcp, iomaps, nr_iomaps);
 }
diff --git a/fs/nfsd/blocklayoutxdr.c b/fs/nfsd/blocklayoutxdr.c
index ce78f74715ee..cb95c5201c1f 100644
--- a/fs/nfsd/blocklayoutxdr.c
+++ b/fs/nfsd/blocklayoutxdr.c
@@ -112,6 +112,25 @@ nfsd4_block_encode_getdeviceinfo(struct xdr_stream *xdr,
 	return 0;
 }
 
+/**
+ * nfsd4_block_decode_layoutupdate - decode the block layout extent array
+ * @p: pointer to the xdr data
+ * @len: number of bytes to decode
+ * @iomapp: pointer to store the decoded array
+ * @block_size: alignment of extent offset and length
+ *
+ * This function decodes the opaque field of the layoutupdate4 structure
+ * in a layoutcommit request for the block layout driver. The field is
+ * actually an array of extents sent by the client. It also checks that
+ * the file offset, storage offset and length of each extent are aligned
+ * by @block_size.
+ *
+ * Return: The number of extents contained in @iomapp on success,
+ * otherwise one of the following negative NFS error codes:
+ *   %-NFS4ERR_BADXDR: The encoded array in @p was invalid.
+ *   %-NFS4ERR_INVAL: An unaligned extent found.
+ *   %-NFS4ERR_DELAY: Failed to allocate memory for @iomapp.
+ */
 int
 nfsd4_block_decode_layoutupdate(__be32 *p, u32 len, struct iomap **iomapp,
 		u32 block_size)
@@ -121,25 +140,25 @@ nfsd4_block_decode_layoutupdate(__be32 *p, u32 len, struct iomap **iomapp,
 
 	if (len < sizeof(u32)) {
 		dprintk("%s: extent array too small: %u\n", __func__, len);
-		return -EINVAL;
+		return -NFS4ERR_BADXDR;
 	}
 	len -= sizeof(u32);
 	if (len % PNFS_BLOCK_EXTENT_SIZE) {
 		dprintk("%s: extent array invalid: %u\n", __func__, len);
-		return -EINVAL;
+		return -NFS4ERR_BADXDR;
 	}
 
 	nr_iomaps = be32_to_cpup(p++);
 	if (nr_iomaps != len / PNFS_BLOCK_EXTENT_SIZE) {
 		dprintk("%s: extent array size mismatch: %u/%u\n",
 			__func__, len, nr_iomaps);
-		return -EINVAL;
+		return -NFS4ERR_BADXDR;
 	}
 
 	iomaps = kcalloc(nr_iomaps, sizeof(*iomaps), GFP_KERNEL);
 	if (!iomaps) {
 		dprintk("%s: failed to allocate extent array\n", __func__);
-		return -ENOMEM;
+		return -NFS4ERR_DELAY;
 	}
 
 	for (i = 0; i < nr_iomaps; i++) {
@@ -181,9 +200,27 @@ nfsd4_block_decode_layoutupdate(__be32 *p, u32 len, struct iomap **iomapp,
 	return nr_iomaps;
 fail:
 	kfree(iomaps);
-	return -EINVAL;
+	return -NFS4ERR_INVAL;
 }
 
+/**
+ * nfsd4_scsi_decode_layoutupdate - decode the scsi layout extent array
+ * @p: pointer to the xdr data
+ * @len: number of bytes to decode
+ * @iomapp: pointer to store the decoded array
+ * @block_size: alignment of extent offset and length
+ *
+ * This function decodes the opaque field of the layoutupdate4 structure
+ * in a layoutcommit request for the scsi layout driver. The field is
+ * actually an array of extents sent by the client. It also checks that
+ * the offset and length of each extent are aligned by @block_size.
+ *
+ * Return: The number of extents contained in @iomapp on success,
+ * otherwise one of the following negative NFS error codes:
+ *   %-NFS4ERR_BADXDR: The encoded array in @p was invalid.
+ *   %-NFS4ERR_INVAL: An unaligned extent found.
+ *   %-NFS4ERR_DELAY: Failed to allocate memory for @iomapp.
+ */
 int
 nfsd4_scsi_decode_layoutupdate(__be32 *p, u32 len, struct iomap **iomapp,
 		u32 block_size)
@@ -193,7 +230,7 @@ nfsd4_scsi_decode_layoutupdate(__be32 *p, u32 len, struct iomap **iomapp,
 
 	if (len < sizeof(u32)) {
 		dprintk("%s: extent array too small: %u\n", __func__, len);
-		return -EINVAL;
+		return -NFS4ERR_BADXDR;
 	}
 
 	nr_iomaps = be32_to_cpup(p++);
@@ -201,13 +238,13 @@ nfsd4_scsi_decode_layoutupdate(__be32 *p, u32 len, struct iomap **iomapp,
 	if (len != expected) {
 		dprintk("%s: extent array size mismatch: %u/%u\n",
 			__func__, len, expected);
-		return -EINVAL;
+		return -NFS4ERR_BADXDR;
 	}
 
 	iomaps = kcalloc(nr_iomaps, sizeof(*iomaps), GFP_KERNEL);
 	if (!iomaps) {
 		dprintk("%s: failed to allocate extent array\n", __func__);
-		return -ENOMEM;
+		return -NFS4ERR_DELAY;
 	}
 
 	for (i = 0; i < nr_iomaps; i++) {
@@ -232,5 +269,5 @@ nfsd4_scsi_decode_layoutupdate(__be32 *p, u32 len, struct iomap **iomapp,
 	return nr_iomaps;
 fail:
 	kfree(iomaps);
-	return -EINVAL;
+	return -NFS4ERR_INVAL;
 }
-- 
2.43.0

On Wed, Jun 11, 2025 at 11:55:02PM +0300, Sergey Bashirov wrote:
>  	if (nr_iomaps < 0)
> -		return nfserrno(nr_iomaps);
> +		return cpu_to_be32(-nr_iomaps);

This still feels like an odd calling convention.  Maybe we should just
change the calling convention to return the __be32 encoded nfs errno
and have a separate output argument for the number of iomaps?

Chuck, any preference?

On 6/12/25 3:00 AM, Christoph Hellwig wrote:
> On Wed, Jun 11, 2025 at 11:55:02PM +0300, Sergey Bashirov wrote:
>>  	if (nr_iomaps < 0)
>> -		return nfserrno(nr_iomaps);
>> +		return cpu_to_be32(-nr_iomaps);
> 
> This still feels like an odd calling convention.  Maybe we should just
> change the calling convention to return the __be32 encoded nfs errno
> and have a separate output argument for the number of iomaps?
> 
> Chuck, any preference?
> 

I thought of using an output argument. This calling convention is not
uncommon in NFS code, and I recall that Linus might prefer avoiding
output arguments?

If I were writing fresh code, I think I would use an output argument
instead of folding results of two different types into a function's
return value.

-- 
Chuck Lever

On Thu, Jun 12, 2025 at 09:10:11AM -0400, Chuck Lever wrote:
> On 6/12/25 3:00 AM, Christoph Hellwig wrote:
> > On Wed, Jun 11, 2025 at 11:55:02PM +0300, Sergey Bashirov wrote:
> >>  	if (nr_iomaps < 0)
> >> -		return nfserrno(nr_iomaps);
> >> +		return cpu_to_be32(-nr_iomaps);
> >
> > This still feels like an odd calling convention.  Maybe we should just
> > change the calling convention to return the __be32 encoded nfs errno
> > and have a separate output argument for the number of iomaps?
> >
> > Chuck, any preference?
> >
>
> I thought of using an output argument. This calling convention is not
> uncommon in NFS code, and I recall that Linus might prefer avoiding
> output arguments?
>
> If I were writing fresh code, I think I would use an output argument
> instead of folding results of two different types into a function's
> return value.

In general, I am ok with either of these two approaches. But I agree
with Christoph that the solution with a separate output argument seems
more natural to me. Should I submit the v3 patch with a separate output
argument?

--
Sergey Bashirov

On 6/12/25 11:57 AM, Sergey Bashirov wrote:
> On Thu, Jun 12, 2025 at 09:10:11AM -0400, Chuck Lever wrote:
>> On 6/12/25 3:00 AM, Christoph Hellwig wrote:
>>> On Wed, Jun 11, 2025 at 11:55:02PM +0300, Sergey Bashirov wrote:
>>>>  	if (nr_iomaps < 0)
>>>> -		return nfserrno(nr_iomaps);
>>>> +		return cpu_to_be32(-nr_iomaps);
>>>
>>> This still feels like an odd calling convention.  Maybe we should just
>>> change the calling convention to return the __be32 encoded nfs errno
>>> and have a separate output argument for the number of iomaps?
>>>
>>> Chuck, any preference?
>>>
>>
>> I thought of using an output argument. This calling convention is not
>> uncommon in NFS code, and I recall that Linus might prefer avoiding
>> output arguments?
>>
>> If I were writing fresh code, I think I would use an output argument
>> instead of folding results of two different types into a function's
>> return value.
> 
> In general, I am ok with either of these two approaches. But I agree
> with Christoph that the solution with a separate output argument seems
> more natural to me. Should I submit the v3 patch with a separate output
> argument?

Yes, thank you!


-- 
Chuck Lever