Linux-NVME Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: John Garry <john.g.garry@oracle.com>
To: Alan Adamson <alan.adamson@oracle.com>, linux-nvme@lists.infradead.org
Cc: kch@nvidia.com, kbusch@kernel.org, hch@lst.de, sagi@grimberg.me
Subject: Re: [PATCH v3 2/2] nvme: all namespaces in a subsystem must adhere to a common atomic write size
Date: Tue, 13 May 2025 10:45:33 +0100	[thread overview]
Message-ID: <9ae170fd-0f27-4da7-b475-61530b061c85@oracle.com> (raw)
In-Reply-To: <20250508223802.277311-3-alan.adamson@oracle.com>

On 08/05/2025 23:38, Alan Adamson wrote:

Sorry for slow response. Generally I think that this is ok, but some 
minor comments below. I might be off the mark with some of them.

> The first namespace configured in a subsystem sets the subsystem's
> atomic write size based on its AWUPF or NAWUPF. Subsequent namespaces
> must have an atomic write size (per their AWUPF or NAWUPF) less than or
> equal to the subsystem's atomic write size, or their probing will be
> rejected.
> 
> Signed-off-by: Alan Adamson <alan.adamson@oracle.com>
> ---
>   drivers/nvme/host/core.c | 29 ++++++++++++++++++++++++++---
>   drivers/nvme/host/nvme.h |  3 ++-
>   2 files changed, 28 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index eb6ea8acb3cc..f34cf69fab8d 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -2059,7 +2059,20 @@ static bool nvme_update_disk_info(struct nvme_ns *ns, struct nvme_id_ns *id,
>   		if (id->nsfeat & NVME_NS_FEAT_ATOMICS && id->nawupf)
>   			atomic_bs = (1 + le16_to_cpu(id->nawupf)) * bs;
>   		else
> -			atomic_bs = (1 + ns->ctrl->subsys->awupf) * bs;
> +			atomic_bs = (1 + ns->ctrl->awupf) * bs;
> +
> +		/*
> +		 * Set subsystem atomic bs.
> +		 */
> +		if (ns->ctrl->subsys->atomic_bs) {
> +			if (atomic_bs > ns->ctrl->subsys->atomic_bs) {

I am not sure why use > and not !=

> +				pr_err_ratelimited(

could dev_err() be used?

"%s: Inconsistent Atomic Write Size,

we could mention that this is the powerfail atomic size, and not 
"normal". But I suppose that we don't use "normal" values anywhere, so 
it could be assumed.

> Namespace will not be added: Subsystem=%d bytes, Controller/Namespace=%d bytes\n",
> +					ns->disk ? ns->disk->disk_name : "?",
> +					ns->ctrl->subsys->atomic_bs,
> +					atomic_bs);
> +			}
> +		} else
> +			ns->ctrl->subsys->atomic_bs = atomic_bs;
>   
>   		nvme_update_atomic_write_disk_info(ns, id, lim, bs, atomic_bs);
>   	}
> @@ -2201,6 +2214,17 @@ static int nvme_update_ns_info_block(struct nvme_ns *ns,
>   	nvme_set_chunk_sectors(ns, id, &lim);
>   	if (!nvme_update_disk_info(ns, id, &lim))
>   		capacity = 0;
> +
> +	/*
> +	 * Validate the max atomic write size fits within the subsystem's
> +	 * atomic write capabilities.
> +	 */
> +	if (lim.atomic_write_hw_max > ns->ctrl->subsys->atomic_bs) {
 > +		blk_mq_unfreeze_queue(ns->disk->queue, memflags);> +		ret = -ENXIO;
> +		goto out;
> +	}
> +
>   	nvme_config_discard(ns, &lim);
>   	if (IS_ENABLED(CONFIG_BLK_DEV_ZONED) &&
>   	    ns->head->ids.csi == NVME_CSI_ZNS)
> @@ -3031,7 +3055,6 @@ static int nvme_init_subsystem(struct nvme_ctrl *ctrl, struct nvme_id_ctrl *id)
>   		kfree(subsys);
>   		return -EINVAL;
>   	}
> -	subsys->awupf = le16_to_cpu(id->awupf);
>   	nvme_mpath_default_iopolicy(subsys);
>   
>   	subsys->dev.class = &nvme_subsys_class;
> @@ -3441,7 +3464,7 @@ static int nvme_init_identify(struct nvme_ctrl *ctrl)
>   		dev_pm_qos_expose_latency_tolerance(ctrl->device);
>   	else if (!ctrl->apst_enabled && prev_apst_enabled)
>   		dev_pm_qos_hide_latency_tolerance(ctrl->device);
> -
> +	ctrl->awupf = le16_to_cpu(id->awupf);
>   out_free:
>   	kfree(id);
>   	return ret;
> diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
> index 51e078642127..ff1d94468613 100644
> --- a/drivers/nvme/host/nvme.h
> +++ b/drivers/nvme/host/nvme.h
> @@ -410,6 +410,7 @@ struct nvme_ctrl {
>   
>   	enum nvme_ctrl_type cntrltype;
>   	enum nvme_dctype dctype;
> +	u16 awupf;

was it intentional to lose the " 0's based awupf value" comment?

>   };
>   
>   static inline enum nvme_ctrl_state nvme_ctrl_state(struct nvme_ctrl *ctrl)
> @@ -442,11 +443,11 @@ struct nvme_subsystem {
>   	u8			cmic;
>   	enum nvme_subsys_type	subtype;
>   	u16			vendor_id;
> -	u16			awupf;	/* 0's based awupf value. */
>   	struct ida		ns_ida;
>   #ifdef CONFIG_NVME_MULTIPATH
>   	enum nvme_iopolicy	iopolicy;
>   #endif
> +	u32			atomic_bs;
>   };
>   
>   /*



  reply	other threads:[~2025-05-13  9:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-08 22:37 [PATCH v3 0/2] NVMe Atomic Write fixes Alan Adamson
2025-05-08 22:38 ` [PATCH v3 1/2] nvme: multipath: enable BLK_FEAT_ATOMIC_WRITES for multipathing Alan Adamson
2025-05-15  2:51   ` Chaitanya Kulkarni
2025-05-08 22:38 ` [PATCH v3 2/2] nvme: all namespaces in a subsystem must adhere to a common atomic write size Alan Adamson
2025-05-13  9:45   ` John Garry [this message]
2025-05-14  5:35     ` Christoph Hellwig
2025-05-14  7:03       ` John Garry
2025-05-14 13:57         ` Christoph Hellwig
2025-05-15  2:54   ` Chaitanya Kulkarni
2025-05-13  6:17 ` [PATCH v3 0/2] NVMe Atomic Write fixes Christoph Hellwig

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=9ae170fd-0f27-4da7-b475-61530b061c85@oracle.com \
    --to=john.g.garry@oracle.com \
    --cc=alan.adamson@oracle.com \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=kch@nvidia.com \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /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