On 10/16/19, 11:58 AM, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote:
NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
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.
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. 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.
--b.
>
> rick
>
> ________________________________________
> From: linux-nfs-owner@xxxxxxxxxxxxxxx <linux-nfs-owner@xxxxxxxxxxxxxxx> on behalf of Rick Macklem <rmacklem@xxxxxxxxxxx>
> Sent: Tuesday, October 15, 2019 10:50 PM
> To: linux-nfs@xxxxxxxxxxxxxxx
> Subject: NFSv4.2 server replies to Copy with length == 0
>
> During interop testing (FreeBSD client->Linux server) of NFSv4.2, my
> client got into a loop. It was because the reply to Copy was NFS_OK,
> but the length in the reply is 0.
> (I'll fix the client to fail for this case so it doesn't loop, but...)
>
> The server is Fedora 30 (5.2.18-200 kernel version).
> It you think this might be fixed in a newer kernel or you'd like me to do
> something with it to get more info, just let me know.
>
> I've attached a snippet of the packet trace. (If the list strips it off, just email
> me and I'll send it to you.)
>
> rick
