]> git.baikalelectronics.ru Git - kernel.git/commit
NFSD: Fix zero-length NFSv3 WRITEs
authorChuck Lever <chuck.lever@oracle.com>
Tue, 21 Dec 2021 16:52:06 +0000 (11:52 -0500)
committerChuck Lever <chuck.lever@oracle.com>
Sat, 8 Jan 2022 19:42:01 +0000 (14:42 -0500)
commitfe1399a453d1ff4bcc1e2159281e0c54f13ab7a0
tree950b7a0ff692a5cb7da12674c93d5463bc2c0407
parentda18f10b9c603ba1b9b16d9fb0d49217efc85fa3
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 939a6925b3d3
("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: 4362e38c5b78 ("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>
fs/nfsd/nfs3proc.c
fs/nfsd/nfsproc.c