public inbox for linux-nvme@lists.infradead.org
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: Niklas Cassel <Niklas.Cassel@wdc.com>
Cc: "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	Kamaljit Singh <Kamaljit.Singh1@wdc.com>,
	Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>,
	Damien Le Moal <dlemoal@kernel.org>
Subject: Re: parallel nvme format
Date: Thu, 14 Dec 2023 15:08:37 -0800	[thread overview]
Message-ID: <ZXuK9YQVkhjwUTr6@kbusch-mbp> (raw)
In-Reply-To: <ZXuGkmdgXwFKB_cY@kbusch-mbp>

On Thu, Dec 14, 2023 at 02:49:54PM -0800, Keith Busch wrote:
> On Thu, Dec 14, 2023 at 09:21:28PM +0000, Niklas Cassel wrote:
> > Perhaps we could introduce a new bit, NVME_CTRL_NEEDS_SCAN or similar?
> > (That gets cleared by nvme_scan_work(), after a scan has been performed.)
> 
> Good point. Updated patch below.
>  
> > I guess for format command specifically, we already have
> > NVME_AER_NOTICE_NS_CHANGED, but that seems to be cleared before by
> > nvme_scan_work() before the mutex is acquired.
> 
> The clearing should just re-arm the controller to send the AER again if
> any other namespace changes. But we can't really depend on the AER
> anyway.
> 
> > And I'm not sure if all command that have
> > effects & (NVME_CMD_EFFECTS_NIC | NVME_CMD_EFFECTS_NCC)
> > set will trigger a NVME_AER_NOTICE_NS_CHANGED AEN.
> 
> We have the "known_effects" for the format command to ensure the driver
> will always request a rescan on a format no matter what a controller
> reports, but yeah, the format could be followed up by another command
> with NVME_CMD_EFFECTS_CSE_MASK set without NIC/NCC, so definitely need
> to retain the need to restart the scan.

The previous diff missed the header update:

diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
index 39a90b7cb1254..79a71b6ae64fe 100644
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -251,6 +251,7 @@ enum nvme_ctrl_flags {
 	NVME_CTRL_STOPPED		= 3,
 	NVME_CTRL_SKIP_ID_CNS_CS	= 4,
 	NVME_CTRL_DIRTY_CAPABILITY	= 5,
+	NVME_CTRL_NEEDS_RESCAN		= 6,
 };

 struct nvme_ctrl {
 
> ---
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index 590cd4f097c22..0b062a2268447 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -1120,6 +1120,8 @@ u32 nvme_passthru_start(struct nvme_ctrl *ctrl, struct nvme_ns *ns, u8 opcode)
>  		nvme_start_freeze(ctrl);
>  		nvme_wait_freeze(ctrl);
>  	}
> +	if (effects & (NVME_CMD_EFFECTS_NIC | NVME_CMD_EFFECTS_NCC))
> +		set_bit(NVME_CTRL_NEEDS_RESCAN, &ctrl->flags);
>  	return effects;
>  }
>  EXPORT_SYMBOL_NS_GPL(nvme_passthru_start, NVME_TARGET_PASSTHRU);
> @@ -1140,7 +1142,7 @@ void nvme_passthru_end(struct nvme_ctrl *ctrl, struct nvme_ns *ns, u32 effects,
>  "controller capabilities changed, reset may be required to take effect.\n");
>  		}
>  	}
> -	if (effects & (NVME_CMD_EFFECTS_NIC | NVME_CMD_EFFECTS_NCC)) {
> +	if (test_bit(NVME_CTRL_NEEDS_RESCAN, &ctrl->flags)) {
>  		nvme_queue_scan(ctrl);
>  		flush_work(&ctrl->scan_work);
>  	}
> @@ -3945,7 +3947,14 @@ static void nvme_scan_work(struct work_struct *work)
>  		nvme_clear_changed_ns_log(ctrl);
>  	}
>  
> -	mutex_lock(&ctrl->scan_lock);
> +	/*
> +	 * Failure to acquire scan_lock means another thread will requeue this
> +	 * work shortly
> +	 */
> +	if (!mutex_trylock(&ctrl->scan_lock))
> +		return;
> +
> +	clear_bit(NVME_CTRL_NEEDS_RESCAN, &ctrl->flags);
>  	if (nvme_ctrl_limited_cns(ctrl)) {
>  		nvme_scan_ns_sequential(ctrl);
>  	} else {
> diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
> index 39a90b7cb1254..79a71b6ae64fe 100644
> --- a/drivers/nvme/host/nvme.h
> +++ b/drivers/nvme/host/nvme.h
> @@ -251,6 +251,7 @@ enum nvme_ctrl_flags {
>  	NVME_CTRL_STOPPED		= 3,
>  	NVME_CTRL_SKIP_ID_CNS_CS	= 4,
>  	NVME_CTRL_DIRTY_CAPABILITY	= 5,
> +	NVME_CTRL_NEEDS_RESCAN		= 6,
>  };
>  
>  struct nvme_ctrl {
> --
> 


  reply	other threads:[~2023-12-14 23:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-14 13:56 parallel nvme format Niklas Cassel
2023-12-14 17:19 ` Keith Busch
2023-12-14 21:21   ` Niklas Cassel
2023-12-14 22:49     ` Keith Busch
2023-12-14 23:08       ` Keith Busch [this message]
     [not found]         ` <BYAPR04MB4151B88FACA25A38C4C998FCBC8CA@BYAPR04MB4151.namprd04.prod.outlook.com>
2023-12-14 23:37           ` Keith Busch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZXuK9YQVkhjwUTr6@kbusch-mbp \
    --to=kbusch@kernel.org \
    --cc=Kamaljit.Singh1@wdc.com \
    --cc=Niklas.Cassel@wdc.com \
    --cc=dlemoal@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=shinichiro.kawasaki@wdc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox