NFSv4.2: Fixup CLONE dest file size for zero-length count

jira LE-1907
Rebuild_History Non-Buildable kernel-rt-5.14.0-284.30.1.rt14.315.el9_2
commit-author Benjamin Coddington <bcodding@redhat.com>
commit 038efb6

When holding a delegation, the NFS client optimizes away setting the
attributes of a file from the GETATTR in the compound after CLONE, and for
a zero-length CLONE we will end up setting the inode's size to zero in
nfs42_copy_dest_done().  Handle this case by computing the resulting count
from the server's reported size after CLONE's GETATTR.

	Suggested-by: Trond Myklebust <trond.myklebust@hammerspace.com>
	Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
Fixes: 94d202d ("NFSv42: Copy offload should update the file size when appropriate")
	Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
(cherry picked from commit 038efb6)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

Author: PlaidCat

fs/nfs/nfs42proc.c

@@ -1093,6 +1093,9 @@ static int _nfs42_proc_clone(struct rpc_message *msg, struct file *src_f,
 				&args.seq_args, &res.seq_res, 0);
 	trace_nfs4_clone(src_inode, dst_inode, &args, status);
 	if (status == 0) {
+		/* a zero-length count means clone to EOF in src */
+		if (count == 0 && res.dst_fattr->valid & NFS_ATTR_FATTR_SIZE)
+			count = nfs_size_to_loff_t(res.dst_fattr->size) - dst_offset;
 		nfs42_copy_dest_done(dst_inode, dst_offset, count);
 		status = nfs_post_op_update_inode(dst_inode, res.dst_fattr);
 	}