All of lore.kernel.org
 help / color / mirror / Atom feed
From: hch@lst.de (Christoph Hellwig)
Subject: [PATCH 5/5] nvme: ANA base support
Date: Sat, 12 May 2018 15:31:23 +0200	[thread overview]
Message-ID: <20180512133123.GA10849@lst.de> (raw)
In-Reply-To: <20180504112845.38820-6-hare@suse.de>

> +static void nvme_get_ana_log(struct nvme_ctrl *ctrl, struct nvme_ns *ns)

Passing a ns to the function reading the ANA log doesn't make any
sense.  The ANA log page is global to the controller, so we should
only read it when rescanning the controller, or when the AER
triggers.

> +static void nvme_get_full_ana_log(struct nvme_ctrl *ctrl)
> +{
> +	int i, j;
> +	struct nvme_ns *ns;
> +	struct nvmf_ana_rsp_page_header *ana_log;
> +	size_t ana_log_size = 4096;

This needs to be size based on the MNAN and NANAGRPID fields.

> +
> +	ana_log = kzalloc(ana_log_size, GFP_KERNEL);
> +	if (!ana_log)
> +		return;

Please preallocate a per-controller buffer at controller scanning
time for this.  By the time path changes hit we might be under
sever memory pressure and want things to just work.

> +
> +	if (nvme_get_log(ctrl, NVME_LOG_ANA, ana_log, ana_log_size))
> +		dev_warn(ctrl->device,
> +			 "Get ANA log error\n");

I think we need some sane error handling here.

> +	list_for_each_entry(ns, &ctrl->namespaces, list) {
> +		for (i = 0; i < ana_log->grpid_num; i++) {
> +			struct nvmf_ana_group_descriptor *desc =
> +				&ana_log->desc[i];
> +			for (j = 0; j < desc->nsid_num; j++) {
> +				if (desc->nsid[j] == ns->head->ns_id) {
> +					ns->ana_state = desc->ana_state;
> +					ns->ana_group = desc->groupid;

What protects us from concurrent updates?  You only hold the
shared semaphore in the caller (which probably should move into
the function to start with).

> +	if ((a == &dev_attr_ana_state.attr) ||
> +	    (a == &dev_attr_ana_group.attr)) {

No need for the inner braces.

> +	/* First round: select from all ANA optimized paths */
>  	list_for_each_entry_rcu(ns, &head->list, siblings) {
> -		if (ns->ctrl->state == NVME_CTRL_LIVE) {
> +		if (ns->ctrl->state == NVME_CTRL_LIVE &&
> +		    ns->ana_state == NVME_ANA_STATE_OPTIMIZED) {
> +			rcu_assign_pointer(head->current_path, ns);
> +			return ns;
> +		}
> +	}
> +	/* Second round: select from all ANA non-optimized paths */
> +	list_for_each_entry_rcu(ns, &head->list, siblings) {
> +		if (ns->ctrl->state == NVME_CTRL_LIVE &&
> +		    ns->ana_state == NVME_ANA_STATE_NONOPTIMIZED) {
>  			rcu_assign_pointer(head->current_path, ns);
>  			return ns;

Based on the last setences in section 8.18.3.3 of the ANA spec
we should also do a last restort attempt at inaccseesible paths.

Also I think we should just pass the state to __nvme_find_path and
retry in the caller to avoid code duplication.

Note that this code seems to miss any handling of the transitioning
state and the error codes related to it, and also doesn't work around
the nasty bit in the spec that allows inaccesible states to report
incorrect capacity, which we'll need to work around by stealing that
data from other namespaces.

  parent reply	other threads:[~2018-05-12 13:31 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-04 11:28 [RFC PATCH 0/5] nvme: ANA support Hannes Reinecke
2018-05-04 11:28 ` [PATCH 1/5] nvmet: EUI64 support Hannes Reinecke
2018-05-07  7:17   ` Johannes Thumshirn
2018-05-09  7:08   ` Christoph Hellwig
2018-05-09  7:45     ` Hannes Reinecke
2018-05-09  7:52       ` Christoph Hellwig
2018-05-09 15:43   ` Ewan D. Milne
2018-05-04 11:28 ` [PATCH 2/5] nvme: Add ANA base definitions Hannes Reinecke
2018-05-04 16:17   ` Keith Busch
2018-05-04 17:03     ` Meneghini, John
2018-05-04 17:21       ` Knight, Frederick
2018-05-05 13:17       ` Hannes Reinecke
2018-05-04 21:12   ` Schremmer, Steven
2018-05-09  7:27   ` Christoph Hellwig
2018-05-04 11:28 ` [PATCH 3/5] nvmet: Add ANA base support Hannes Reinecke
2018-05-06  2:42   ` Guan Junxiong
2018-05-04 11:28 ` [PATCH 4/5] block: BLK_STS_NEXUS is a path failure Hannes Reinecke
2018-05-09  7:31   ` Christoph Hellwig
2018-05-04 11:28 ` [PATCH 5/5] nvme: ANA base support Hannes Reinecke
2018-05-04 22:11   ` Schremmer, Steven
2018-05-05 13:23     ` Hannes Reinecke
2018-05-06  3:23   ` Guan Junxiong
2018-05-07  7:21   ` Johannes Thumshirn
2018-05-09 18:49   ` Ewan D. Milne
2018-05-09 19:03   ` Ewan D. Milne
2018-05-10  9:16     ` Sriram Popuri
     [not found]     ` <CAGYjvj0Mk0MFAfUEApOOyQ9Prm3CvGcZH14PJzDQT2+Qc+w81w@mail.gmail.com>
2018-05-10 13:40       ` Hannes Reinecke
2018-05-11  7:50       ` Hannes Reinecke
2018-05-11  8:22         ` Popuri, Sriram
2018-05-11  8:36           ` Popuri, Sriram
2018-05-11 16:24             ` Knight, Frederick
2018-05-12 13:31   ` Christoph Hellwig [this message]
2018-05-13 10:33     ` Hannes Reinecke

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=20180512133123.GA10849@lst.de \
    --to=hch@lst.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.