]> www.infradead.org Git - users/jedix/linux-maple.git/commit
svcrdma: Change maximum server payload back to RPCSVC_MAXPAYLOAD
authorChuck Lever <chuck.lever@oracle.com>
Tue, 25 Aug 2015 19:33:49 +0000 (13:33 -0600)
committerChuck Lever <chuck.lever@oracle.com>
Mon, 31 Aug 2015 20:45:58 +0000 (14:45 -0600)
commit48e31807252c9bf98a384dd2317dba51db10c80c
tree0ab4253d120f6eae9967b5f5dc850781001be9a4
parent73de9c85d0b7dbdae057461e4ec1425e0c467794
svcrdma: Change maximum server payload back to RPCSVC_MAXPAYLOAD

[ Queued for upstream v4.3 ]

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>
include/linux/sunrpc/svc_rdma.h
net/sunrpc/xprtrdma/svc_rdma_transport.c
net/sunrpc/xprtrdma/xprt_rdma.h