diff options
author | Chuck Lever <chuck.lever@oracle.com> | 2019-02-11 11:23:49 -0500 |
---|---|---|
committer | Anna Schumaker <Anna.Schumaker@Netapp.com> | 2019-02-13 10:19:06 -0500 |
commit | d4550bbee66f4ba5a5e9bbe8055006332ebfc58b (patch) | |
tree | 38770a38bc030fe76aa5320a73538611973eba7b /net/sunrpc/auth_null.c | |
parent | xprtrdma: Fix sparse warnings (diff) | |
download | linux-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