From: Ming Lei <ming.lei@redhat.com>
To: Uday Shankar <ushankar@purestorage.com>
Cc: Jens Axboe <axboe@kernel.dk>, Jonathan Corbet <corbet@lwn.net>,
linux-block@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH v3 4/5] ublk: support device recovery without I/O queueing
Date: Fri, 4 Oct 2024 23:34:47 +0800 [thread overview]
Message-ID: <ZwALFzPLAW1AbW-J@fedora> (raw)
In-Reply-To: <20241002220949.3087902-5-ushankar@purestorage.com>
On Wed, Oct 02, 2024 at 04:09:48PM -0600, Uday Shankar wrote:
> ublk currently supports the following behaviors on ublk server exit:
>
> A: outstanding I/Os get errors, subsequently issued I/Os get errors
> B: outstanding I/Os get errors, subsequently issued I/Os queue
> C: outstanding I/Os get reissued, subsequently issued I/Os queue
>
> and the following behaviors for recovery of preexisting block devices by
> a future incarnation of the ublk server:
>
> 1: ublk devices stopped on ublk server exit (no recovery possible)
> 2: ublk devices are recoverable using start/end_recovery commands
>
> The userspace interface allows selection of combinations of these
> behaviors using flags specified at device creation time, namely:
>
> default behavior: A + 1
> UBLK_F_USER_RECOVERY: B + 2
> UBLK_F_USER_RECOVERY|UBLK_F_USER_RECOVERY_REISSUE: C + 2
>
> The behavior A + 2 is currently unsupported. Add support for this
> behavior under the new flag combination
> UBLK_F_USER_RECOVERY|UBLK_F_USER_RECOVERY_FAIL_IO.
>
> Signed-off-by: Uday Shankar <ushankar@purestorage.com>
> ---
> Changes since v2 (https://lore.kernel.org/linux-block/20240917002155.2044225-5-ushankar@purestorage.com/):
> - Clean up logic in ublk_ctrl_end_recovery
>
> drivers/block/ublk_drv.c | 78 ++++++++++++++++++++++++++++-------
> include/uapi/linux/ublk_cmd.h | 18 ++++++++
> 2 files changed, 81 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
> index d5edef7bde43..f2a05dcbc58b 100644
> --- a/drivers/block/ublk_drv.c
> +++ b/drivers/block/ublk_drv.c
> @@ -60,10 +60,12 @@
> | UBLK_F_UNPRIVILEGED_DEV \
> | UBLK_F_CMD_IOCTL_ENCODE \
> | UBLK_F_USER_COPY \
> - | UBLK_F_ZONED)
> + | UBLK_F_ZONED \
> + | UBLK_F_USER_RECOVERY_FAIL_IO)
>
> #define UBLK_F_ALL_RECOVERY_FLAGS (UBLK_F_USER_RECOVERY \
> - | UBLK_F_USER_RECOVERY_REISSUE)
> + | UBLK_F_USER_RECOVERY_REISSUE \
> + | UBLK_F_USER_RECOVERY_FAIL_IO)
>
> /* All UBLK_PARAM_TYPE_* should be included here */
> #define UBLK_PARAM_TYPE_ALL \
> @@ -146,6 +148,7 @@ struct ublk_queue {
> bool force_abort;
> bool timeout;
> bool canceling;
> + bool fail_io; /* copy of dev->state == UBLK_S_DEV_FAIL_IO */
> unsigned short nr_io_ready; /* how many ios setup */
> spinlock_t cancel_lock;
> struct ublk_device *dev;
> @@ -690,7 +693,8 @@ static inline bool ublk_nosrv_should_reissue_outstanding(struct ublk_device *ub)
> */
> static inline bool ublk_nosrv_dev_should_queue_io(struct ublk_device *ub)
> {
> - return ub->dev_info.flags & UBLK_F_USER_RECOVERY;
> + return (ub->dev_info.flags & UBLK_F_USER_RECOVERY) &&
> + !(ub->dev_info.flags & UBLK_F_USER_RECOVERY_FAIL_IO);
> }
>
> /*
> @@ -700,7 +704,8 @@ static inline bool ublk_nosrv_dev_should_queue_io(struct ublk_device *ub)
> */
> static inline bool ublk_nosrv_should_queue_io(struct ublk_queue *ubq)
> {
> - return ubq->flags & UBLK_F_USER_RECOVERY;
> + return (ubq->flags & UBLK_F_USER_RECOVERY) &&
> + !(ubq->flags & UBLK_F_USER_RECOVERY_FAIL_IO);
> }
>
> /*
> @@ -714,6 +719,12 @@ static inline bool ublk_nosrv_should_stop_dev(struct ublk_device *ub)
> return !(ub->dev_info.flags & UBLK_F_USER_RECOVERY);
> }
>
> +static inline bool ublk_dev_in_recoverable_state(struct ublk_device *ub)
> +{
> + return ub->dev_info.state == UBLK_S_DEV_QUIESCED ||
> + ub->dev_info.state == UBLK_S_DEV_FAIL_IO;
> +}
> +
> static void ublk_free_disk(struct gendisk *disk)
> {
> struct ublk_device *ub = disk->private_data;
> @@ -1275,6 +1286,10 @@ static blk_status_t ublk_queue_rq(struct blk_mq_hw_ctx *hctx,
> struct request *rq = bd->rq;
> blk_status_t res;
>
> + if (unlikely(ubq->fail_io)) {
> + return BLK_STS_TARGET;
> + }
> +
> /* fill iod to slot in io cmd buffer */
> res = ublk_setup_iod(ubq, rq);
> if (unlikely(res != BLK_STS_OK))
> @@ -1625,6 +1640,7 @@ static void ublk_nosrv_work(struct work_struct *work)
> {
> struct ublk_device *ub =
> container_of(work, struct ublk_device, nosrv_work);
> + int i;
>
> if (ublk_nosrv_should_stop_dev(ub)) {
> ublk_stop_dev(ub);
> @@ -1634,7 +1650,18 @@ static void ublk_nosrv_work(struct work_struct *work)
> mutex_lock(&ub->mutex);
> if (ub->dev_info.state != UBLK_S_DEV_LIVE)
> goto unlock;
> - __ublk_quiesce_dev(ub);
> +
> + if (ublk_nosrv_dev_should_queue_io(ub)) {
> + __ublk_quiesce_dev(ub);
> + } else {
> + blk_mq_quiesce_queue(ub->ub_disk->queue);
> + for (i = 0; i < ub->dev_info.nr_hw_queues; i++) {
> + ublk_get_queue(ub, i)->fail_io = true;
> + }
> + blk_mq_unquiesce_queue(ub->ub_disk->queue);
> + ub->dev_info.state = UBLK_S_DEV_FAIL_IO;
The above state update should be moved before blk_mq_unquiesce_queue().
Otherwise, this patch is fine.
Thanks,
Ming
next prev parent reply other threads:[~2024-10-04 15:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-02 22:09 [PATCH v3 0/5] ublk: support device recovery without I/O queueing Uday Shankar
2024-10-02 22:09 ` [PATCH v3 1/5] ublk: check recovery flags for validity Uday Shankar
2024-10-02 22:09 ` [PATCH v3 2/5] ublk: refactor recovery configuration flag helpers Uday Shankar
2024-10-04 15:32 ` Ming Lei
2024-10-02 22:09 ` [PATCH v3 3/5] ublk: merge stop_work and quiesce_work Uday Shankar
2024-10-02 22:09 ` [PATCH v3 4/5] ublk: support device recovery without I/O queueing Uday Shankar
2024-10-04 15:34 ` Ming Lei [this message]
2024-10-02 22:09 ` [PATCH v3 5/5] Documentation: ublk: document UBLK_F_USER_RECOVERY_FAIL_IO Uday Shankar
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=ZwALFzPLAW1AbW-J@fedora \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=corbet@lwn.net \
--cc=linux-block@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=ushankar@purestorage.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.