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