quoted

quoted

quoted

-	if (ctrl->ctrl.state == NVME_CTRL_LIVE)
+	if (test_bit(NVME_RDMA_Q_CONNECTED, &ctrl->queues[0].flags))
 		nvme_shutdown_ctrl(&ctrl->ctrl);

 	blk_mq_stop_hw_queues(ctrl->ctrl.admin_q);

Maybe the right way to handle this is to unconditionally call
nvme_shutdown_ctrl and make sure we return an early error
on the register write?

As I wrote on patch 2/5 reply, I'd like to avoid depending on
queue_rq to fail early peeking at the ctrl state. This dependency
can grow in the future and I think we should at least try not to
go there...

I don't want ->queue_rq to peek at controller state.  What I had
in mind was copying the PCIe behavior of failing early in the
timeout handler if we are in the reset handler, which will
mean blk_execute_rq will return ASAP with an error.

Do we want the unnecessary ADMIN_TIMEOUT for sending a shutdown
on a queue we know is not connected? I'm worried it will have scale
issues...
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html