2022년 6월 14일 (화) 오후 8:56, Tom Talpey <tom@xxxxxxxxxx>님이 작성:
>
>
> 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?
>
There was an issue that ksmbd got stuck after attempting to shutdown.
We are trying to reproduce it, but we haven't reproduced it yet,
but It seems to be related to the TIMEWAIT event.
And other drivers such as nvme have disconnected on the TIMEWAIT event.
> 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.
Right, ksmbd doesn't reuse QP.
>
> Tom.
--
Thanks,
Hyunchul
