aboutsummaryrefslogtreecommitdiffstats
path: root/net/sunrpc/auth_null.c
diff options
context:
space:
mode:
authorChuck Lever <chuck.lever@oracle.com>2019-02-11 11:23:49 -0500
committerAnna Schumaker <Anna.Schumaker@Netapp.com>2019-02-13 10:19:06 -0500
commitd4550bbee66f4ba5a5e9bbe8055006332ebfc58b (patch)
tree38770a38bc030fe76aa5320a73538611973eba7b /net/sunrpc/auth_null.c
parentxprtrdma: Fix sparse warnings (diff)
downloadlinux-dev-d4550bbee66f4ba5a5e9bbe8055006332ebfc58b.tar.xz
linux-dev-d4550bbee66f4ba5a5e9bbe8055006332ebfc58b.zip
xprtrdma: Check inline size before providing a Write chunk
In very rare cases, an NFS READ operation might predict that the non-payload part of the RPC Call is large. For instance, an NFSv4 COMPOUND with a large GETATTR result, in combination with a large Kerberos credential, could push the non-payload part to be several kilobytes. If the non-payload part is larger than the connection's inline threshold, the client is required to provision a Reply chunk. The current Linux client does not check for this case. There are two obvious ways to handle it: a. Provision a Write chunk for the payload and a Reply chunk for the non-payload part b. Provision a Reply chunk for the whole RPC Reply Some testing at a recent NFS bake-a-thon showed that servers can mostly handle a. but there are some corner cases that do not work yet. b. already works (it has to, to handle krb5i/p), but could be somewhat less efficient. However, I expect this scenario to be very rare -- no-one has reported a problem yet. So I'm going to implement b. Sometime later I will provide some patches to help make b. a little more efficient by more carefully choosing the Reply chunk's segment sizes to ensure the payload is optimally aligned. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Diffstat (limited to 'net/sunrpc/auth_null.c')
0 files changed, 0 insertions, 0 deletions