| Message ID | 164329914731.5879.7791856151631542523.stgit@bazille.1015granger.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | NFSD size, offset, and count sanity | expand |
Ooh, lots to consider for Ganesha... And I see you are proposing a new pynfs test case, which I will have to remember the thought behind it and make sure that's covered for NFS v3 when I get back to the pynfs 3 tests. Frank > -----Original Message----- > From: Chuck Lever [mailto:chuck.lever@oracle.com] > Sent: Thursday, January 27, 2022 8:08 AM > To: linux-nfs@vger.kernel.org; linux-fsdevel@vger.kernel.org > Subject: [PATCH RFC 0/6] NFSD size, offset, and count sanity > > 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
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