All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
	linux-scsi@vger.kernel.org,
	"Martin K . Petersen" <martin.petersen@oracle.com>
Subject: Re: [PATCH v3 2/7] block: introduce storage element management
Date: Wed, 7 Oct 2026 15:35:37 +0200	[thread overview]
Message-ID: <20261007133537.GB31906@lst.de> (raw)
In-Reply-To: <20261007082344.1049179-3-dlemoal@kernel.org>

On Wed, Oct 07, 2026 at 05:23:39PM +0900, Damien Le Moal wrote:
> Co-developed-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>

That's a lot of credit for the two or three trivial fixes that got
folded in, I'd drop that line.

> +static int disk_wait_for_se_mgmt_completion(struct gendisk *disk)
> +{
> +	struct blk_storage_element *elements, *e;
> +	unsigned int i, nr_se, nr_elements = 0;
> +	unsigned int noio_flag;
> +	int ret;
> +
> +	/* The callers already checked that disk->fops->se_ops is set. */
> +	ret = disk->fops->se_ops->report_elements(disk, NULL, &nr_elements);

Sashikoa thing report_elements could be zero.  Which is of course
a bit stupid, but maybe we can protect against that by checking that
all members are set at registration time for the bdops?

> +	/*
> +	 * Poll the storage elements heath state to detect the end of a removal
> +	 * or restoration operation. Since we do not know how long the operation

Overly long line.

> +	 * may take, we cannot have a timeout on this loop. So make it
> +	 * interruptible by a fatal signal so that the user can terminate this
> +	 * retry loop if the device misbehaves.
> +	 */
> +	while (!fatal_signal_pending(current)) {
> +		/*
> +		 * Check if we have storage elements being removed or restored.
> +		 */
> +		nr_se = nr_elements;

Declare شr_se locally in the loop?

> +		ret = disk->fops->se_ops->report_elements(disk, elements,
> +							  &nr_se);
> +		if (ret) {
> +			pr_err("Failed to get storage elements\n");
> +			break;
> +		}
> +
> +		e = elements;

Same for e?  And maybe factor this entire loop into a helper to make
sure nothing leaks out.

> +		for (i = 0; i < nr_se; i++, e++) {
> +			if (e->status == BLK_SE_STS_REMOVE_IN_PROGRESS ||
> +			    e->status == BLK_SE_STS_RESTORE_IN_PROGRESS)
> +				break;

Switch?  And yeah, the Sashiko comment on the error handling here
looks correct to me.

> +		if (i >= nr_se)
> +			break;

And this looks a bit odd.  Why not use a goto to get out instead of
this nesting (splitting it into a separate helper would take care
of that with a direct return as well).

> +		/* Not done yet: wait and retry. */
> +		msleep(1000);

It would be nice to have a UA for this in future spec versions
instead of he busy wait.

> + * Fill at most @nr_elements storage element descriptors in the array @elements.
> + * The number of storage elements filled in the array is returned using
> + * @nr_elements. If @elements is NULL, only @nr_elements is returned to indicate

Overly long lines.


  parent reply	other threads:[~2026-10-07 13:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-07  8:23 [PATCH v3 0/7] Add support for storage element depopulation Damien Le Moal
2026-10-07  8:23 ` [PATCH v3 1/7] block: fail reads to offline zones early Damien Le Moal
2026-10-07  8:41   ` sashiko-bot
2026-10-07 13:29   ` Christoph Hellwig
2026-10-07 14:31     ` Damien Le Moal
2026-10-07  8:23 ` [PATCH v3 2/7] block: introduce storage element management Damien Le Moal
2026-10-07  8:34   ` sashiko-bot
2026-10-07 13:35   ` Christoph Hellwig [this message]
2026-10-07 14:35     ` Damien Le Moal
2026-10-07  8:23 ` [PATCH v3 3/7] block: add storage element management ioctls Damien Le Moal
2026-10-07  8:39   ` sashiko-bot
2026-10-07 13:39   ` Christoph Hellwig
2026-10-07 14:37     ` Damien Le Moal
2026-10-07 15:28       ` Christoph Hellwig
2026-10-07  8:23 ` [PATCH v3 4/7] zloop: add storage element emulation Damien Le Moal
2026-10-07  8:35   ` sashiko-bot
2026-10-07 13:40   ` Christoph Hellwig
2026-10-07  8:23 ` [PATCH v3 5/7] zloop: add degrade_element control command Damien Le Moal
2026-10-07  8:39   ` sashiko-bot
2026-10-07  8:23 ` [PATCH v3 6/7] scsi: sd_zbc: always revalidate zones for disks supporting head depopulation Damien Le Moal
2026-10-07  8:35   ` sashiko-bot
2026-10-07  8:23 ` [PATCH v3 7/7] scsi: sd_zbc: define storage element management operations Damien Le Moal
2026-10-07  8:40   ` sashiko-bot

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=20261007133537.GB31906@lst.de \
    --to=hch@lst.de \
    --cc=axboe@kernel.dk \
    --cc=dlemoal@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.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 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.