summaryrefslogtreecommitdiff
path: root/.cocciconfig
diff options
context:
space:
mode:
authorChuck Lever <chuck.lever@oracle.com>2021-12-21 19:52:06 +0300
committerChuck Lever <chuck.lever@oracle.com>2022-01-08 22:42:01 +0300
commit6a2f774424bfdcc2df3e17de0cefe74a4269cad5 (patch)
tree950b7a0ff692a5cb7da12674c93d5463bc2c0407 /.cocciconfig
parent47446d74f1707049067fee038507cdffda805631 (diff)
downloadlinux-6a2f774424bfdcc2df3e17de0cefe74a4269cad5.tar.xz
NFSD: Fix zero-length NFSv3 WRITEs
The Linux NFS server currently responds to a zero-length NFSv3 WRITE request with NFS3ERR_IO. It responds to a zero-length NFSv4 WRITE with NFS4_OK and count of zero. RFC 1813 says of the WRITE procedure's @count argument: count The number of bytes of data to be written. If count is 0, the WRITE will succeed and return a count of 0, barring errors due to permissions checking. RFC 8881 has similar language for NFSv4, though NFSv4 removed the explicit @count argument because that value is already contained in the opaque payload array. The synthetic client pynfs's WRT4 and WRT15 tests do emit zero- length WRITEs to exercise this spec requirement. Commit fdec6114ee1f ("nfsd4: zero-length WRITE should succeed") addressed the same problem there with the same fix. But interestingly the Linux NFS client does not appear to emit zero- length WRITEs, instead squelching them. I'm not aware of a test that can generate such WRITEs for NFSv3, so I wrote a naive C program to generate a zero-length WRITE and test this fix. Fixes: 8154ef2776aa ("NFSD: Clean up legacy NFS WRITE argument XDR decoders") Reported-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Diffstat (limited to '.cocciconfig')
0 files changed, 0 insertions, 0 deletions