Dan Aloni reported a problem with the way NFSD's READ implementation
deals with the very upper end of file sizes, and I got interested in
how some of the other operations handled it. I found some issues,
and have started a (growing) pile of patches to deal with them.
Since at least the SETATTR case appears to cause a crash on some
filesystems, I think several of these are 5.17-rc fodder (i.e.,
priority bug fixes). I see that NLM also has potential problems with
how the max file size is handled, but since locking doesn't involve
the page cache, I think fixes in that area can be delayed a bit.
Dan's still working on the READ issue. I need some input on whether
I understand the problem correctly and whether the NFS status codes
I've chosen to use are going to be reasonable or a problem for NFS
clients. I've attempted to stay within the bound of the NFS specs,
but sometimes the spec doesn't provide a mechanism in the protocol
to indicate that the client passed us a bogus size/offset/count.
---
Chuck Lever (6):
NFSD: Fix NFSv4 SETATTR's handling of large file sizes
NFSD: Fix NFSv3 SETATTR's handling of large file sizes
NFSD: COMMIT operations must not return NFS?ERR_INVAL
NFSD: Replace directory offset placeholder
NFSD: Remove NFS_OFFSET_MAX
NFSD: Clamp WRITE offsets
fs/nfsd/nfs3proc.c | 32 +++++++++++++++++++++------
fs/nfsd/nfs3xdr.c | 4 ++--
fs/nfsd/nfs4proc.c | 7 +++++-
fs/nfsd/nfs4xdr.c | 2 +-
fs/nfsd/vfs.c | 53 ++++++++++++++++++++++++++++++---------------
fs/nfsd/vfs.h | 4 ++--
include/linux/nfs.h | 8 -------
7 files changed, 72 insertions(+), 38 deletions(-)
--
Chuck Lever
