Bug 2170423

Summary:	server-side copy fails with IO error when server responds with NFS4ERR_OFFLOAD_DENIED
Product:	Red Hat Enterprise Linux 9	Reporter:	Tigran Mkrtchyan <tigran.mkrtchyan>
Component:	kernel	Assignee:	Benjamin Coddington <bcodding>
kernel sub component:	NFS	QA Contact:	JianHong Yin <jiyin>
Status:	CLOSED ERRATA	Docs Contact:
Severity:	unspecified
Priority:	unspecified	CC:	bcodding, bstinson, jwboyer, nfs-team, xzhou, yieli, yoyang
Version:	CentOS Stream	Keywords:	Triaged
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	kernel-5.14.0-302.el9	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-11-07 08:41:16 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tigran Mkrtchyan 2023-02-16 10:43:24 UTC

Description of problem:

According to rfc7862#11.1.2.1:

  11.1.2.1.  NFS4ERR_OFFLOAD_DENIED (Error Code 10091)

   The COPY offload operation is supported by both the source and the
   destination, but the destination is not allowing it for this file.
   If the client sees this error, it should fall back to the normal copy
   semantics.

NOTE that according to rfc7862#section-4.1 in intra-server case "source server"
and "destination server" are the same server.

However, if the server indeed returns the NFS4ERR_OFFLOAD_DENIED, then the client application will receive EIO error.

Version-Release number of selected component (if applicable):

kernel-5.14.0-252.el9

How reproducible:
100%

Steps to Reproduce:
1. instruct the server to return NFS4ERR_OFFLOAD_DENIED on COPY request
2. run a regular cp operation


Actual results:
cp fails with EIO


Expected results:
nfs client falls back to read-write semantics.


Additional info:
The upstream patch should address that behavior

http://git.linux-nfs.org/?p=anna/linux-nfs.git;a=commitdiff;h=4730515378a70064581b27ed112fcfc6f2a379ca#patch1

Comment 1 Benjamin Coddington 2023-02-21 12:04:22 UTC

This one's obviously correct, we'll take it when it gets merged upstream.

Comment 4 Yongcheng Yang 2023-03-08 02:23:09 UTC

(In reply to Benjamin Coddington from comment #1)
> This one's obviously correct, we'll take it when it gets merged upstream.

We need to request exception or blocker for this late ITM.

Comment 6 Benjamin Coddington 2023-03-08 10:44:24 UTC

(In reply to Yongcheng Yang from comment #4)
> (In reply to Benjamin Coddington from comment #1)
> > This one's obviously correct, we'll take it when it gets merged upstream.
> 
> We need to request exception or blocker for this late ITM.

Ah, I meant to boot this one to 9.3..  we'll still get it done now so that it is on c9s.  I expect this is a rare issue, and if we get a customer with it on 9.2 we can send it to z-stream.

Comment 20 errata-xmlrpc 2023-11-07 08:41:16 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: kernel security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2023:6583