On 2021/3/16 1:08, Sagi Grimberg wrote:

quoted

quoted

quoted

A crash happens when set feature(NVME_FEAT_NUM_QUEUES) timeout in nvme
over rdma(roce) reconnection, the reason is use the queue which is not
alloced.

If queue is not live, should not allow queue request.

Can you describe exactly the scenario here? What is the state
here? LIVE? or DELETING?

If seting feature(NVME_FEAT_NUM_QUEUES) failed due to time out or
the target return 0 io queues, nvme_set_queue_count will return 0,
and then reconnection will continue and success. The state of controller
is LIVE. The request will continue to deliver by call ->queue_rq(),
and then crash happens.

Thinking about this again, we should absolutely fail the reconnection
when we are unable to set any I/O queues, it is just wrong to
keep this controller alive...

Keith think keeping the controller alive for diagnose is better.
This is the patch which failed the connection.
https://lore.kernel.org/linux-nvme/20210223072602.3196-1-lengchao@huawei.com/ (local)

Now we have 2 choice:
1.failed the connection when unable to set any I/O queues.
2.do not allow queue request when queue is not live.

 From a service continuity perspective, I think it is better that failed
the connection when unable to set any I/O queues.
Diagnose is less important, I prefer service continuity, because if failed
the reconnection and then try new reconnection, it is possible to recover.

This should be fixed for both rdma and tcp.
.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme