]> git.baikalelectronics.ru Git - kernel.git/commit
xprtrdma: Don't defer fencing an async RPC's chunks
authorChuck Lever <chuck.lever@oracle.com>
Mon, 9 Oct 2017 16:03:26 +0000 (12:03 -0400)
committerAnna Schumaker <Anna.Schumaker@Netapp.com>
Mon, 16 Oct 2017 17:51:27 +0000 (13:51 -0400)
commit5b275e8d78046a65b81971f2da9761a90f65523a
tree4f2b720ab78f3afd3344da28b799c11e106b9128
parent9194e3374262009eaf4b6a1504c991dbb0156548
xprtrdma: Don't defer fencing an async RPC's chunks

In current kernels, waiting in xprt_release appears to be safe to
do. I had erroneously believed that for ASYNC RPCs, waiting of any
kind in xprt_release->xprt_rdma_free would result in deadlock. I've
done injection testing and consulted with Trond to confirm that
waiting in the RPC release path is safe.

For the very few times where RPC resources haven't yet been released
earlier by the reply handler, it is safe to wait synchronously in
xprt_rdma_free for invalidation rather than defering it to MR
recovery.

Note: When the QP is error state, posting a LocalInvalidate should
flush and mark the MR as bad. There is no way the remote HCA can
access that MR via a QP in error state, so it is effectively already
inaccessible and thus safe for the Upper Layer to access. The next
time the MR is used it should be recognized and cleaned up properly
by frwr_op_map.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
net/sunrpc/xprtrdma/transport.c