aboutsummaryrefslogtreecommitdiffstats
path: root/security/keys/Makefile
diff options
context:
space:
mode:
authorTom Tucker <tom@ogc.us>2011-02-09 19:45:34 +0000
committerTrond Myklebust <Trond.Myklebust@netapp.com>2011-03-11 15:39:27 -0500
commit5c635e09cec0feeeb310968e51dad01040244851 (patch)
tree6f776276df4d20b221c02f776a677f8719f9a0aa /security/keys/Makefile
parentbd7ea31b9e8a342be76e0fe8d638343886c2d8c5 (diff)
downloadkernel_samsung_crespo-5c635e09cec0feeeb310968e51dad01040244851.zip
kernel_samsung_crespo-5c635e09cec0feeeb310968e51dad01040244851.tar.gz
kernel_samsung_crespo-5c635e09cec0feeeb310968e51dad01040244851.tar.bz2
RPCRDMA: Fix FRMR registration/invalidate handling.
When the rpc_memreg_strategy is 5, FRMR are used to map RPC data. This mode uses an FRMR to map the RPC data, then invalidates (i.e. unregisers) the data in xprt_rdma_free. These FRMR are used across connections on the same mount, i.e. if the connection goes away on an idle timeout and reconnects later, the FRMR are not destroyed and recreated. This creates a problem for transport errors because the WR that invalidate an FRMR may be flushed (i.e. fail) leaving the FRMR valid. When the FRMR is later used to map an RPC it will fail, tearing down the transport and starting over. Over time, more and more of the FRMR pool end up in the wrong state resulting in seemingly random disconnects. This fix keeps track of the FRMR state explicitly by setting it's state based on the successful completion of a reg/inv WR. If the FRMR is ever used and found to be in the wrong state, an invalidate WR is prepended, re-syncing the FRMR state and avoiding the connection loss. Signed-off-by: Tom Tucker <tom@ogc.us> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Diffstat (limited to 'security/keys/Makefile')
0 files changed, 0 insertions, 0 deletions