nvme async-connect and discovery uevents

The 'reconnect_work' function does exactly the same than we do for the initial connect, so we can as well schedule the workqueue item here and wait for it to complete.

Signed-off-by Hannes Reinecke <hare at suse.com>

---
  drivers/nvme/host/rdma.c | 20 +++++++++++++-------
  1 file changed, 13 insertions(+), 7 deletions(-)

drivers/nvme/host/rdma.c +0 -0

index dc042017c293..0906acbb800e 100644

drivers/nvme/host/rdma.c +6 -6

-	if (ret)
-		goto out_uninit_ctrl;
-
-	dev_info(ctrl->ctrl.device, "new ctrl: NQN \"%s\", addr %pISpcs\n",
-		ctrl->ctrl.opts->subsysnqn, &ctrl->addr);
-
  	nvme_get_ctrl(&ctrl->ctrl);
 
  	mutex_lock(&nvme_rdma_ctrl_mutex);
  	list_add_tail(&ctrl->list, &nvme_rdma_ctrl_list);
  	mutex_unlock(&nvme_rdma_ctrl_mutex);
 
+	if (!queue_delayed_work(nvme_wq, &ctrl->reconnect_work, 0)) {
+		nvme_put_ctrl(&ctrl->ctrl);
+		dev_err(ctrl->ctrl.device,
+			"failed to schedule initial connect\n");
+		goto out_uninit_ctrl;
+	}

Quoted 3 lines · Hannes Reinecke

The 'reconnect_work' function does exactly the same than we do for the initial connect, so we can as well schedule the workqueue item here and wait for it to complete.

If we do this we should rename it to connect_work.

Quoted 6 lines

Signed-off-by Hannes Reinecke <hare at suse.com>

---
? drivers/nvme/host/rdma.c | 20 +++++++++++++------- ? 1 file changed, 13 insertions(+), 7 deletions(-)

drivers/nvme/host/rdma.c static struct nvme_ctrl · line 1994

Quoted 10 lines

drivers/nvme/host/rdma.c +0 -0

index dc042017c293..0906acbb800e 100644
@@ -1990,19 +1990,25 @@ static struct nvme_ctrl
 *nvme_rdma_create_ctrl(struct device *dev,
 ????? changed = nvme_change_ctrl_state(&ctrl->ctrl,
 NVME_CTRL_CONNECTING);
 ????? WARN_ON_ONCE(!changed);
 ? -??? ret = nvme_rdma_setup_ctrl(ctrl, true);

we call nvme_rdma_setup_ctrl with "new == true" here and with "new == false" in the reconnect work.
so how does this work ?

Quoted 21 lines

drivers/nvme/host/rdma.c +10 -6

-??? if (ret)
-??????? goto out_uninit_ctrl;
-
-??? dev_info(ctrl->ctrl.device, "new ctrl: NQN \"%s\", addr %pISpcs\n",
-??????? ctrl->ctrl.opts->subsysnqn, &ctrl->addr);
-
 ????? nvme_get_ctrl(&ctrl->ctrl);
 ? ????? mutex_lock(&nvme_rdma_ctrl_mutex);
 ????? list_add_tail(&ctrl->list, &nvme_rdma_ctrl_list);
 ????? mutex_unlock(&nvme_rdma_ctrl_mutex);
 ? +??? if (!queue_delayed_work(nvme_wq, &ctrl->reconnect_work, 0)) {
+??????? nvme_put_ctrl(&ctrl->ctrl);
+??????? dev_err(ctrl->ctrl.device,
+??????????? "failed to schedule initial connect\n");
+??????? goto out_uninit_ctrl;
+??? }
+
+??? flush_delayed_work(&ctrl->reconnect_work);
+
+??? dev_info(ctrl->ctrl.device, "new ctrl: NQN \"%s\", addr %pISpcs\n",
+??????? ctrl->ctrl.opts->subsysnqn, &ctrl->addr);

Quoted 5 lines

drivers/nvme/host/rdma.c +2 -0

+
+
 ????? return &ctrl->ctrl;

? ? out_uninit_ctrl:

what is the benefit here ?
We have more lines of code now :)

drivers/nvme/host/fc.c +2 -1

index 611e70cae754..90b4d8df275b 100644
@@ -3081,7 +3081,8 @@ nvme_fc_init_ctrl(struct device *dev, struct nvmf_ctrl_options *opts,
  		goto fail_ctrl;
  	}
 
-	flush_delayed_work(&ctrl->connect_work);
+	if (!opts->async_connect)
+		flush_delayed_work(&ctrl->connect_work);
 
  	dev_info(ctrl->ctrl.device,
  		"NVME-FC{%d}: new ctrl: NQN \"%s\"\n",

drivers/nvme/host/rdma.c +0 -0

index 0906acbb800e..82917dba9452 100644

When establishing a connection to the discovery controller with the 'async-connect' option the cli has no means of actually getting the discovery log page entries.
This patch implements a 'discovery' sysfs attribute for the controller which holds the information of the discovery log page. Additionally an uevent is generated for each discovery log page entry.

Signed-off-by Hannes Reinecke <hare at suse.com>

---
  drivers/nvme/host/core.c | 163 ++++++++++++++++++++++++++++++++++++++++++++++-
  drivers/nvme/host/nvme.h |   1 +
  2 files changed, 163 insertions(+), 1 deletion(-)

drivers/nvme/host/core.c +13 -0

index dd8ec1dd9219..358be6d217d9 100644
@@ -2325,6 +2325,133 @@ static int nvme_get_effects_log(struct nvme_ctrl *ctrl)
  	return ret;
  }
 
+static int nvme_get_discovery_log(struct nvme_ctrl *ctrl)
+{
+	int ret, disc_log_len = 4096;
+
+retry:
+	if (!ctrl->discovery)
+		ctrl->discovery = kzalloc(disc_log_len, GFP_KERNEL);
+
+	if (!ctrl->discovery)
+		return 0;
+
+	ret = nvme_get_log(ctrl, NVME_NSID_ALL, NVME_LOG_DISC, 0,
+			   ctrl->discovery, disc_log_len, 0);

drivers/nvme/host/core.c +4 -0

+	}
+	return ret;
+}
+

drivers/nvme/host/core.c +35 -0

+
+	ret = nvme_get_discovery_log(ctrl);
+	if (!ret && ctrl->discovery) {
+		int i;
+		struct nvmf_disc_rsp_page_entry *entry =
+			ctrl->discovery->entries;
+
+		for (i = 0; i < ctrl->discovery->numrec; i++) {
+			nvme_discovery_uevent(ctrl, entry);
+			entry++;
+		}
+	}
+	return ret;
+}
+
  /*
   * Initialize the cached copies of the Identify data and various controller
   * register in our nvme_ctrl structure.  This should be called as soon as

@@ -2491,6 +2618,10 @@ int nvme_init_identify(struct nvme_ctrl *ctrl)
  	if (ret < 0)
  		return ret;
 
+	ret = nvme_configure_discovery(ctrl);
+	if (ret < 0)
+		return ret;
+
  	ctrl->identified = true;
 
  	return 0;

@@ -2825,6 +2956,32 @@ static ssize_t nvme_sysfs_show_address(struct device *dev,
  }
  static DEVICE_ATTR(address, S_IRUGO, nvme_sysfs_show_address, NULL);
 
+static ssize_t nvme_discovery_show(struct device *dev,
+				   struct device_attribute *attr,
+				   char *buf)
+{
+	struct nvme_ctrl *ctrl = dev_get_drvdata(dev);
+	struct nvmf_disc_rsp_page_entry *entry;
+	int i;
+	ssize_t len = 0;
+
+	if (!ctrl->discovery)
+		return -EINVAL;
+
+	entry = ctrl->discovery->entries;
+	for (i = 0; i < ctrl->discovery->numrec; i++) {
+		len += snprintf(buf, PAGE_SIZE,
+				"trtype %d adrfam %d traddr %s "

drivers/nvme/host/core.c +5 -1

  static struct attribute *nvme_dev_attrs[] = {
  	&dev_attr_reset_controller.attr,
  	&dev_attr_rescan_controller.attr,

@@ -2836,6 +2993,7 @@ static struct attribute *nvme_dev_attrs[] = {
  	&dev_attr_transport.attr,
  	&dev_attr_subsysnqn.attr,
  	&dev_attr_address.attr,
+	&dev_attr_discovery.attr,
  	&dev_attr_state.attr,
  	NULL
  };

@@ -2850,7 +3008,9 @@ static umode_t nvme_dev_attrs_are_visible(struct kobject *kobj,
  		return 0;
  	if (a == &dev_attr_address.attr && !ctrl->ops->get_address)
  		return 0;
-
+	if (a == &dev_attr_discovery.attr && ctrl->opts &&
+	    !ctrl->opts->discovery_nqn)
+		return 0;
  	return a->mode;
  }
 

@@ -3496,6 +3656,7 @@ static void nvme_free_ctrl(struct device *dev)
 
  	ida_simple_remove(&nvme_instance_ida, ctrl->instance);
  	kfree(ctrl->effects);
+	kfree(ctrl->discovery);
  	nvme_mpath_uninit(ctrl);
 
  	if (subsys) {

drivers/nvme/host/nvme.h +1 -0

index bb4a2003c097..8a4ed46b986b 100644
@@ -199,6 +199,7 @@ struct nvme_ctrl {
  	unsigned long quirks;
  	struct nvme_id_power_state psd[32];
  	struct nvme_effects_log *effects;
+	struct nvmf_disc_rsp_page_hdr *discovery;
  	struct work_struct scan_work;
  	struct work_struct async_event_work;
  	struct delayed_work ka_work;

Quoted 40 lines · Hannes Reinecke

When establishing a connection to the discovery controller with the 'async-connect' option the cli has no means of actually getting the discovery log page entries.
This patch implements a 'discovery' sysfs attribute for the controller which holds the information of the discovery log page. Additionally an uevent is generated for each discovery log page entry.

Signed-off-by Hannes Reinecke <hare at suse.com>

---
? drivers/nvme/host/core.c | 163
++++++++++++++++++++++++++++++++++++++++++++++-
? drivers/nvme/host/nvme.h |?? 1 +
? 2 files changed, 163 insertions(+), 1 deletion(-)

drivers/nvme/host/core.c +17 -0

index dd8ec1dd9219..358be6d217d9 100644
@@ -2325,6 +2325,133 @@ static int nvme_get_effects_log(struct
 nvme_ctrl *ctrl)
 ????? return ret;
 ? }
 ? +static int nvme_get_discovery_log(struct nvme_ctrl *ctrl)
+{
+??? int ret, disc_log_len = 4096;
+
+retry:
+??? if (!ctrl->discovery)
+??????? ctrl->discovery = kzalloc(disc_log_len, GFP_KERNEL);
+
+??? if (!ctrl->discovery)
+??????? return 0;
+
+??? ret = nvme_get_log(ctrl, NVME_NSID_ALL, NVME_LOG_DISC, 0,
+?????????????? ctrl->discovery, disc_log_len, 0);
+??? if (ret) {
+??????? kfree(ctrl->discovery);
+??????? ctrl->discovery = NULL;
+??????? return ret;
+??? }

drivers/nvme/host/core.c static int nvme_get_effects_log(struct · line 2350

Quoted 5 lines

drivers/nvme/host/core.c +5 -0

+??? if (ctrl->discovery->numrec > 3 && disc_log_len == 4096) {
+??????? disc_log_len = (ctrl->discovery->numrec + 1) * 1024;
+??????? kfree(ctrl->discovery);
+??????? ctrl->discovery = NULL;
+??????? goto retry;

This is missing logic to detect a change in GENCTR and restart the log read.

Quoted 4 lines

drivers/nvme/host/core.c +4 -0

+??? }
+??? return ret;
+}
+

drivers/nvme/host/core.c static int nvme_get_effects_log(struct

Quoted 10 lines

drivers/nvme/host/core.c +9 -0

...
+static int nvme_configure_discovery(struct nvme_ctrl *ctrl)
+{
+??? int ret = 0;
+
+??? if (!ctrl->opts || !ctrl->opts->discovery_nqn)
+??????? return 0;
+
+??? if (!ctrl->opts->async_connect)
+??????? return 0;

I don't understand why async_connect parameter means anything in this context...? why is this looked at?

is it strictly to avoid delay while reading the discovery log ?? I don't know that waiting for yet another command or two is a big deal, so I would think just proceeding with reading the discovery log is fine.

Quoted 49 lines

drivers/nvme/host/core.c +15 -0

+
+??? ret = nvme_get_discovery_log(ctrl);
+??? if (!ret && ctrl->discovery) {
+??????? int i;
+??????? struct nvmf_disc_rsp_page_entry *entry =
+??????????? ctrl->discovery->entries;
+
+??????? for (i = 0; i < ctrl->discovery->numrec; i++) {
+??????????? nvme_discovery_uevent(ctrl, entry);
+??????????? entry++;
+??????? }
+??? }
+??? return ret;
+}
+

? /*
?? * Initialize the cached copies of the Identify data and various controller
?? * register in our nvme_ctrl structure.? This should be called as soon as

drivers/nvme/host/core.c +18 -0

@@ -2491,6 +2618,10 @@ int nvme_init_identify(struct nvme_ctrl *ctrl)
 ????? if (ret < 0)
 ????????? return ret;
 ? +??? ret = nvme_configure_discovery(ctrl);
+??? if (ret < 0)
+??????? return ret;
+
 ????? ctrl->identified = true;
 ? ????? return 0;

@@ -2825,6 +2956,32 @@ static ssize_t nvme_sysfs_show_address(struct
 device *dev,
 ? }
 ? static DEVICE_ATTR(address, S_IRUGO, nvme_sysfs_show_address, NULL);
 ? +static ssize_t nvme_discovery_show(struct device *dev,
+?????????????????? struct device_attribute *attr,
+?????????????????? char *buf)
+{
+??? struct nvme_ctrl *ctrl = dev_get_drvdata(dev);
+??? struct nvmf_disc_rsp_page_entry *entry;
+??? int i;
+??? ssize_t len = 0;
+
+??? if (!ctrl->discovery)
+??????? return -EINVAL;
+
+??? entry = ctrl->discovery->entries;
+??? for (i = 0; i < ctrl->discovery->numrec; i++) {
+??????? len += snprintf(buf, PAGE_SIZE,
+??????????????? "trtype %d adrfam %d traddr %s "

drivers/nvme/host/core.c static ssize_t nvme_sysfs_show_address(struct · line 2984

Quoted 10 lines

drivers/nvme/host/core.c +10 -0

+??????????????? "trsvcid %s portid %d subnqn %s\n",
+??????????????? entry->trtype, entry->adrfam, entry->traddr,
+??????????????? entry->trsvcid, le16_to_cpu(entry->portid),
+??????????????? entry->subnqn);
+??????? entry++;
+??? }
+??? return len;
+}
+static DEVICE_ATTR(discovery, S_IRUGO, nvme_discovery_show, NULL);
+

I really don't like that it's reporting a cached log. ? It may be completely inconsistent with what's on the discovery controller now (consider a nvmetcli done then a reconfig done). ?? There may not even be connectivity to the discovery controller at the time the sysfs entry is read - so validity to the content is in question.? I would much rather have the attribute read the log then display contents - so it's always current.??? Of course that does make it interesting if you read it while the controller is paused doing a reconnect.

Quoted 43 lines · James Smart

Quoted 40 lines · Hannes Reinecke

When establishing a connection to the discovery controller with the 'async-connect' option the cli has no means of actually getting the discovery log page entries.
This patch implements a 'discovery' sysfs attribute for the controller which holds the information of the discovery log page. Additionally an uevent is generated for each discovery log page entry.

Signed-off-by Hannes Reinecke <hare at suse.com>

---
? drivers/nvme/host/core.c | 163
++++++++++++++++++++++++++++++++++++++++++++++-
? drivers/nvme/host/nvme.h |?? 1 +
? 2 files changed, 163 insertions(+), 1 deletion(-)

drivers/nvme/host/core.c +17 -0

index dd8ec1dd9219..358be6d217d9 100644
@@ -2325,6 +2325,133 @@ static int nvme_get_effects_log(struct
 nvme_ctrl *ctrl)
 ????? return ret;
 ? }
 ? +static int nvme_get_discovery_log(struct nvme_ctrl *ctrl)
+{
+??? int ret, disc_log_len = 4096;
+
+retry:
+??? if (!ctrl->discovery)
+??????? ctrl->discovery = kzalloc(disc_log_len, GFP_KERNEL);
+
+??? if (!ctrl->discovery)
+??????? return 0;
+
+??? ret = nvme_get_log(ctrl, NVME_NSID_ALL, NVME_LOG_DISC, 0,
+?????????????? ctrl->discovery, disc_log_len, 0);
+??? if (ret) {
+??????? kfree(ctrl->discovery);
+??????? ctrl->discovery = NULL;
+??????? return ret;
+??? }

Quoted 9 lines

drivers/nvme/host/core.c static int nvme_get_effects_log(struct · line 2350

Quoted 5 lines

drivers/nvme/host/core.c +5 -0

+??? if (ctrl->discovery->numrec > 3 && disc_log_len == 4096) {
+??????? disc_log_len = (ctrl->discovery->numrec + 1) * 1024;
+??????? kfree(ctrl->discovery);
+??????? ctrl->discovery = NULL;
+??????? goto retry;

This is missing logic to detect a change in GENCTR and restart the log read.

Yeah, I'll be implementing this for the next round.

Quoted 18 lines

Quoted 4 lines

drivers/nvme/host/core.c +4 -0

+??? }
+??? return ret;
+}
+

drivers/nvme/host/core.c static int nvme_get_effects_log(struct

Quoted 10 lines

drivers/nvme/host/core.c +9 -0

...
+static int nvme_configure_discovery(struct nvme_ctrl *ctrl)
+{
+??? int ret = 0;
+
+??? if (!ctrl->opts || !ctrl->opts->discovery_nqn)
+??????? return 0;
+
+??? if (!ctrl->opts->async_connect)
+??????? return 0;

I don't understand why async_connect parameter means anything in this context...? why is this looked at?

Quoted 4 lines

is it strictly to avoid delay while reading the discovery log ?? I don't know that waiting for yet another command or two is a big deal, so I would think just proceeding with reading the discovery log is fine.

Originally I did that so as to restore the original functionality, and tie discovery events to the use of the 'async_connect' parameter. But you are right, both are not necessarily connected.
I'll drop this for the next round.

Quoted 60 lines

Quoted 49 lines

drivers/nvme/host/core.c +15 -0

+
+??? ret = nvme_get_discovery_log(ctrl);
+??? if (!ret && ctrl->discovery) {
+??????? int i;
+??????? struct nvmf_disc_rsp_page_entry *entry =
+??????????? ctrl->discovery->entries;
+
+??????? for (i = 0; i < ctrl->discovery->numrec; i++) {
+??????????? nvme_discovery_uevent(ctrl, entry);
+??????????? entry++;
+??????? }
+??? }
+??? return ret;
+}
+

? /*
?? * Initialize the cached copies of the Identify data and various controller
?? * register in our nvme_ctrl structure.? This should be called as soon as

drivers/nvme/host/core.c +18 -0

@@ -2491,6 +2618,10 @@ int nvme_init_identify(struct nvme_ctrl *ctrl)
 ????? if (ret < 0)
 ????????? return ret;
 ? +??? ret = nvme_configure_discovery(ctrl);
+??? if (ret < 0)
+??????? return ret;
+
 ????? ctrl->identified = true;
 ? ????? return 0;

@@ -2825,6 +2956,32 @@ static ssize_t nvme_sysfs_show_address(struct
 device *dev,
 ? }
 ? static DEVICE_ATTR(address, S_IRUGO, nvme_sysfs_show_address, NULL);
 ? +static ssize_t nvme_discovery_show(struct device *dev,
+?????????????????? struct device_attribute *attr,
+?????????????????? char *buf)
+{
+??? struct nvme_ctrl *ctrl = dev_get_drvdata(dev);
+??? struct nvmf_disc_rsp_page_entry *entry;
+??? int i;
+??? ssize_t len = 0;
+
+??? if (!ctrl->discovery)
+??????? return -EINVAL;
+
+??? entry = ctrl->discovery->entries;
+??? for (i = 0; i < ctrl->discovery->numrec; i++) {
+??????? len += snprintf(buf, PAGE_SIZE,
+??????????????? "trtype %d adrfam %d traddr %s "

drivers/nvme/host/core.c static ssize_t nvme_sysfs_show_address(struct · line 2984

Quoted 10 lines

drivers/nvme/host/core.c +10 -0

+??????????????? "trsvcid %s portid %d subnqn %s\n",
+??????????????? entry->trtype, entry->adrfam, entry->traddr,
+??????????????? entry->trsvcid, le16_to_cpu(entry->portid),
+??????????????? entry->subnqn);
+??????? entry++;
+??? }
+??? return len;
+}
+static DEVICE_ATTR(discovery, S_IRUGO, nvme_discovery_show, NULL);
+

Quoted 9 lines

I really don't like that it's reporting a cached log. ? It may be completely inconsistent with what's on the discovery controller now (consider a nvmetcli done then a reconfig done). ?? There may not even be connectivity to the discovery controller at the time the sysfs entry is read - so validity to the content is in question.? I would much rather have the attribute read the log then display contents - so it's always current.??? Of course that does make it interesting if you read it while the controller is paused doing a reconnect.

For the next round I'll split this patch in two, one for getting the discovery log and issueing uevents, and a next onw for the sysfs attribute. After all, I've implemented the sysfs attribute just for completeness, to show the contents of the internal discovery buffer. Re-reading it when reading kind of defeats that purpose IMO.

If the CLI crashes before the 'disconnect' command is issued or when the 'async_connect' option is used the controller is never removed. This patch cleans up stale discovery controllers after 2 minutes,

Signed-off-by Hannes Reinecke <hare at suse.com>

---
  drivers/nvme/host/core.c    | 5 +++++
  drivers/nvme/host/fabrics.c | 2 +-
  drivers/nvme/host/nvme.h    | 1 +
  3 files changed, 7 insertions(+), 1 deletion(-)

drivers/nvme/host/core.c +5 -0

index 358be6d217d9..b3738b327731 100644
@@ -866,6 +866,11 @@ static void nvme_keep_alive_work(struct work_struct *work)
  	struct nvme_ctrl *ctrl = container_of(to_delayed_work(work),
  			struct nvme_ctrl, ka_work);
 
+	if (ctrl->opts->discovery_nqn) {
+		nvme_delete_ctrl(ctrl);
+		return;
+	}
+
  	if (nvme_keep_alive(ctrl)) {
  		/* allocation failure, reset the controller */
  		dev_err(ctrl->device, "keep-alive failed\n");

drivers/nvme/host/fabrics.c +1 -1

index e484205b4cad..b98662760051 100644
@@ -827,7 +827,7 @@ static int nvmf_parse_options(struct nvmf_ctrl_options *opts,
  	}
 
  	if (opts->discovery_nqn) {
-		opts->kato = 0;
+		opts->kato = NVME_DISCOVERY_TIMEOUT;
  		opts->nr_io_queues = 0;
  		opts->duplicate_connect = true;
  	}

drivers/nvme/host/nvme.h +0 -0

index 8a4ed46b986b..551a6b1dbc8c 100644

Quoted 47 lines · Hannes Reinecke

If the CLI crashes before the 'disconnect' command is issued or when the 'async_connect' option is used the controller is never removed. This patch cleans up stale discovery controllers after 2 minutes,

Signed-off-by Hannes Reinecke <hare at suse.com>

---

? drivers/nvme/host/core.c??? | 5 +++++
? drivers/nvme/host/fabrics.c | 2 +-
? drivers/nvme/host/nvme.h??? | 1 +

? 3 files changed, 7 insertions(+), 1 deletion(-)

drivers/nvme/host/core.c +4 -0

index 358be6d217d9..b3738b327731 100644
@@ -866,6 +866,11 @@ static void nvme_keep_alive_work(struct
 work_struct *work)
 ????? struct nvme_ctrl *ctrl = container_of(to_delayed_work(work),
 ????????????? struct nvme_ctrl, ka_work);
 ? +??? if (ctrl->opts->discovery_nqn) {
+??????? nvme_delete_ctrl(ctrl);
+??????? return;
+??? }
+
 ????? if (nvme_keep_alive(ctrl)) {

????????? /* allocation failure, reset the controller */ ????????? dev_err(ctrl->device, "keep-alive failed\n");

drivers/nvme/host/fabrics.c +1 -1

index e484205b4cad..b98662760051 100644
@@ -827,7 +827,7 @@ static int nvmf_parse_options(struct
 nvmf_ctrl_options *opts,
 ????? }
 ? ????? if (opts->discovery_nqn) {
-??????? opts->kato = 0;
+??????? opts->kato = NVME_DISCOVERY_TIMEOUT;
 ????????? opts->nr_io_queues = 0;
 ????????? opts->duplicate_connect = true;
 ????? }

drivers/nvme/host/nvme.h +0 -0

index 8a4ed46b986b..551a6b1dbc8c 100644
@@ -32,6 +32,7 @@ extern unsigned int admin_timeout;

? ? #define NVME_DEFAULT_KATO??? 5
? #define NVME_KATO_GRACE??????? 10

Quoted 3 lines

+#define NVME_DISCOVERY_TIMEOUT??? 120
? ? extern struct workqueue_struct *nvme_wq;
? extern struct workqueue_struct *nvme_reset_wq;

this doesn't necessarily track to the new TP that adds kato support to discovery controllers, nor the fabric spec update that has the host tracking kato and deleting the controller (whether discovery controller or not) (the actual kato as set on the controller with the grace period).

I would rather have this be a generic timer on a host that tracks to the kato timeout and deletes the controller (doesn't matter if discovery or not) if kato times out.??? If the controller is an older discovery controller that doesn't support kato - then the 1st kato timeout should fail and remove the controller.? If it's newer and supports kato, it would be assumed the controller stays live for an extended period- just like a storage controller.