On 6/13/2022 7:01 PM, Hyunchul Lee wrote:
After a QP has been disconnected, it stays
in a timewait state for in flight packets.
After the state has completed,
RDMA_CM_EVENT_TIMEWAIT_EXIT is reported.
Disconnect on RDMA_CM_EVENT_TIMEWAIT_EXIT
so that ksmbd can restart.
Signed-off-by: Hyunchul Lee <hyc.lee@xxxxxxxxx>
---
fs/ksmbd/transport_rdma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/ksmbd/transport_rdma.c b/fs/ksmbd/transport_rdma.c
index d035e060c2f0..4b1a471afcd0 100644
--- a/fs/ksmbd/transport_rdma.c
+++ b/fs/ksmbd/transport_rdma.c
@@ -1535,6 +1535,7 @@ static int smb_direct_cm_handler(struct rdma_cm_id *cm_id,
wake_up_interruptible(&t->wait_status);
break;
}
+ case RDMA_CM_EVENT_TIMEWAIT_EXIT:
case RDMA_CM_EVENT_DEVICE_REMOVAL:
case RDMA_CM_EVENT_DISCONNECTED: {
t->status = SMB_DIRECT_CS_DISCONNECTED;
Is this issue seen on all RDMA providers? Because I would normally
expect that an RDMA_CM_EVENT_DISCONNECTED will precede the TIMEWAIT
event. What scenarios have you seen this not occur?
Unless ksmbd wishes to reuse its QP's, which is not currently the
case (right?), there's pretty much no reason to manage QP state and
hang around for TIMEWAIT.
Tom.
