Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Rick Macklem <rmacklem@uoguelph.ca>
To:     "J. Bruce Fields" <bfields@fieldses.org>,
        "Kornievskaia, Olga" <Olga.Kornievskaia@netapp.com>
CC:     "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
        "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: Re: NFSv4.2 server replies to Copy with length == 0
Thread-Topic: NFSv4.2 server replies to Copy with length == 0
Thread-Index: AQHVg8vy6XBow5lmmE6IMuCp/6tuzqdcytI+gACiuwCAAEGxgIAACqQAgABZSj+AAC45/Q==
Date:   Thu, 17 Oct 2019 04:43:58 +0000
Message-ID: <YQBPR0101MB16526D76EE6A574D31EDF9DBDD6D0@YQBPR0101MB1652.CANPRD01.PROD.OUTLOOK.COM>
References: <YQBPR0101MB1652856488503987CEB17738DD920@YQBPR0101MB1652.CANPRD01.PROD.OUTLOOK.COM>
 <YQBPR0101MB1652DEF8AD7A6169D44D47C6DD920@YQBPR0101MB1652.CANPRD01.PROD.OUTLOOK.COM>
 <20191016155838.GA17543@fieldses.org>
 <31E6043B-090D-4E37-B66F-A45AC0CFC970@netapp.com>,<20191016203150.GC17543@fieldses.org>,<YQBPR0101MB16524CABD71AACBD2D9DC651DD6D0@YQBPR0101MB1652.CANPRD01.PROD.OUTLOOK.COM>
In-Reply-To: <YQBPR0101MB16524CABD71AACBD2D9DC651DD6D0@YQBPR0101MB1652.CANPRD01.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: uoguelph.ca does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0b532b86-b219-4ae1-3cde-08d752bca025
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2019 04:43:58.9629
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: stdXW7FiJNNYFTXWuCBc8Jd5hrliCYSdvb/eb0YA9uqdpGg2MjFlnNpD6TlFZQA3mZsz7OgVFd6ofqTckcBrLw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB0948
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org

Rick wrote:
>I have added nfsv4@ietf.org to the cc list, since I think it is important that
>everyone involved in NFSv4.2 be aware of this.
>
>>J. Bruce Fields wrote:
>>On Wed, Oct 16, 2019 at 07:53:45PM +0000, Kornievskaia, Olga wrote:
>>> On 10/16/19, 11:58 AM, "J. Bruce Fields" <bfields@fieldses.org> wrote:
>>>     On Wed, Oct 16, 2019 at 06:22:42AM +0000, Rick Macklem wrote:
>>>     > It seems that the Copy reply with wr_count == 0 occurs when the
>>>     > client sends a Copy request with ca_src_offset beyond EOF in the
>>>     > input file.  (It happened because I was testing an old/broken
>>>     > version of my client, but I can reproduce it, if you need a
>>>     > bugfix to be tested. I don't know if the case of
>>>     > ca_src_offset+ca_count beyond EOF behaves the same?) --> The RFC
>>>     > seems to require a reply of NFS4ERR_INVAL for this case.
>>>
>>>     I've never understood that INVAL requirement.  But I know it's
>>>     been discussed before, maybe there was some justification for it
>>>     that I've forgotten.
>No longer overly relevant, since the RFC is now a published spec.
>(It may have just been consistent with the old copy_file_range(2) semantics?)
>
>>>
>>> Sigh, well, I don?t know if we should consider adding the check to the
>>> NFS server to be NFS spec compliant. VFS layer didn't want the check
>>> and instead the preference has been to keep read() semantics of
>>> returning a short read (when the len was beyond the end of the file or
>>> if the source) to something beyond the end of the file.
>>
>>I'm inclined to think the spec's just wrong.
>The RFC is not wrong, although it might not be your preferred semantic.
>(It would only be wrong if it was unimplementable.)
>
>As for patching the server, I am not sure if that is a good idea now or not?
>- I would like to see the Linux NFSv4.2 server conform to the RFC, however
>   it has already shipped in its current form.
>--> I think that all extant clients need to handle both reply semantics and,
>       once that is the case, patching the server to conform to the RFC would
>       be nice.
>
>I have now found two cases where the Linux NFSv4.2 server does not conform
>to RFC-7862. One is as above and the other is a reply to Seek of NFS4ERR_NXIO
>when the sa_offset argument == file_size (instead of replying NFS_OK along
>with sr_eof == true).
>
>Since I now know about these two cases, I can code the client to handle
>both of them. Of course, I do worry about others that I have not found yet.
>
>>And how else could a client possibly interpret a 0 return?
>The FreeBSD client looped, because it does a Copy in a loop until all bytes
>were copied and, with a reply length == 0, it didn't make progress or
>recognize an error.
>
>Fortunately, this client is still under development (not yet released), so I can
>add code to handle wr_count == 0 in the same way as NFS4ERR_INVAL.
>
>>> On the client if VFS did read of len=0 then VFS itself we return 0,
>>> thus this doesn't protect against other clients sending an NFS copy
>>> with len=0.  And in NFS, receiving copy with len=0 means copy to the
>>> end of the file. It's not implemented for any "intra" or "inter" code.
>Are you saying that an NFSv4.2 Copy request with a ca_count == 0
>will not work for the Linux NFSv4.2 server?
>(I guess I'd better test this one, too.)
Tested it and it does not work, at least for Fedora30.
The server just returns 0 instead of doing a copy to EOF on the input file.
I think you should implement this, although my client does not do this now.

>>A call with len=0 sounds like a different case.
Yes, as above.
>>
>>--b.

rick