Looks good to me. Just 's/supplics/supplies/'.
Without looking into the entire code, If we can change the type of max_reconnect and nr_reconnects to unsigned int then we can just get away with the one comparison (ctrl->nr_reconnects < ctrl->opts->max_reconnects). Reviewed-by: Chaitanya Kulkarni <[email protected]> From: Linux-nvme <[email protected]> on behalf of Tal Shorer <[email protected]> Sent: Tuesday, August 7, 2018 1:42 PM To: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Cc: Tal Shorer Subject: [PATCH] nvme: fabrics: fix ctrl_loss_tmo < 0 to reconnect forever When the user supplics ctrl_loss_tmo < 0, we warn them that this will cause the fabrics layer to attempt reconnection forever. However, in reality the fabrics layer never attempts to reconnect because the condition to test whether we should reconnect is backwards in this case. Signed-off-by: Tal Shorer <[email protected]> --- drivers/nvme/host/fabrics.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nvme/host/fabrics.c b/drivers/nvme/host/fabrics.c index f7efe5a58cc7..206d63cb1afc 100644 --- a/drivers/nvme/host/fabrics.c +++ b/drivers/nvme/host/fabrics.c @@ -474,7 +474,7 @@ EXPORT_SYMBOL_GPL(nvmf_connect_io_queue); bool nvmf_should_reconnect(struct nvme_ctrl *ctrl) { - if (ctrl->opts->max_reconnects != -1 && + if (ctrl->opts->max_reconnects == -1 || ctrl->nr_reconnects < ctrl->opts->max_reconnects) return true; -- 2.14.1 _______________________________________________ Linux-nvme mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-nvme
