summaryrefslogtreecommitdiff
path: root/fs/nfsd/nfssvc.c
diff options
context:
space:
mode:
authorChuck Lever <chuck.lever@oracle.com>2015-08-07 20:55:46 (GMT)
committerJ. Bruce Fields <bfields@redhat.com>2015-08-10 20:04:57 (GMT)
commitcc9a903d915c21626b6b2fbf8ed0ff16a7f82210 (patch)
treec7b2579914374bc880f0aa51f3f80b879b3cf224 /fs/nfsd/nfssvc.c
parent31193fe5f6fb616711323f5d74ee5bb92aacba4a (diff)
downloadlinux-cc9a903d915c21626b6b2fbf8ed0ff16a7f82210.tar.xz
svcrdma: Change maximum server payload back to RPCSVC_MAXPAYLOAD
Both commit 0380a3f375 ("svcrdma: Add a separate "max data segs" macro for svcrdma") and commit 7e5be28827bf ("svcrdma: advertise the correct max payload") are incorrect. This commit reverts both changes, restoring the server's maximum payload size to 1MB. Commit 7e5be28827bf based the server's maximum payload on the _client's_ RPCRDMA_MAX_DATA_SEGS value. That was wrong. Commit 0380a3f375 tried to fix this so that the client maximum payload size could be raised without affecting the server, but managed to confuse matters more on the server side. More importantly, limiting the advertised maximum payload size was meant to be a workaround, not the actual fix. We need to revisit https://bugzilla.linux-nfs.org/show_bug.cgi?id=270 A Linux client on a platform with 64KB pages can overrun and crash an x86_64 NFS/RDMA server when the r/wsize is 1MB. An x86/64 Linux client seems to work fine using 1MB reads and writes when the Linux server's maximum payload size is restored to 1MB. BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=270 Fixes: 0380a3f375 ("svcrdma: Add a separate "max data segs" macro") Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Diffstat (limited to 'fs/nfsd/nfssvc.c')
0 files changed, 0 insertions, 0 deletions