summaryrefslogtreecommitdiff
path: root/net/sunrpc/auth_gss
diff options
context:
space:
mode:
authorChuck Lever <chuck.lever@oracle.com>2016-09-06 18:22:49 +0300
committerTrond Myklebust <trond.myklebust@primarydata.com>2016-09-06 22:59:35 +0300
commit78d506e1b7071b24850fd5ac22b896c459b0a04c (patch)
tree141a19e4872ffcd39c6f181680820d0b6ac418b6 /net/sunrpc/auth_gss
parent334a8f37115bf35e38617315a360a91ac4f2b2c6 (diff)
downloadlinux-78d506e1b7071b24850fd5ac22b896c459b0a04c.tar.xz
xprtrdma: Revert 3d4cf35bd4fa ("xprtrdma: Reply buffer exhaustion...")
Receive buffer exhaustion, if it were to actually occur, would be catastrophic. However, when there are no reply buffers to post, that means all of them have already been posted and are waiting for incoming replies. By design, there can never be more RPCs in flight than there are available receive buffers. A receive buffer can be left posted after an RPC exits without a received reply; say, due to a credential problem or a soft timeout. This does not result in fewer posted receive buffers than there are pending RPCs, and there is already logic in xprtrdma to deal appropriately with this case. It also looks like the "+ 2" that was removed was accidentally accommodating the number of extra receive buffers needed for receiving backchannel requests. That will need to be addressed by another patch. Fixes: 3d4cf35bd4fa ("xprtrdma: Reply buffer exhaustion can be...") Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Diffstat (limited to 'net/sunrpc/auth_gss')
0 files changed, 0 insertions, 0 deletions