From: Uday Shankar <ushankar@purestorage.com>
To: Ming Lei <ming.lei@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org,
Caleb Sander Mateos <csander@purestorage.com>
Subject: Re: [PATCH 8/9] ublk: simplify aborting ublk request
Date: Mon, 14 Apr 2025 14:42:19 -0600 [thread overview]
Message-ID: <Z/1zK7ycY+iLZBmL@dev-ushankar.dev.purestorage.com> (raw)
In-Reply-To: <20250414112554.3025113-9-ming.lei@redhat.com>
On Mon, Apr 14, 2025 at 07:25:49PM +0800, Ming Lei wrote:
> Now ublk_abort_queue() is moved to ublk char device release handler,
> meantime our request queue is "quiesced" because either ->canceling was
> set from uring_cmd cancel function or all IOs are inflight and can't be
> completed by ublk server, things becomes easy much:
>
> - all uring_cmd are done, so we needn't to mark io as UBLK_IO_FLAG_ABORTED
> for handling completion from uring_cmd
>
> - ublk char device is closed, no one can hold IO request reference any more,
> so we can simply complete this request or requeue it for ublk_nosrv_should_reissue_outstanding.
>
> Signed-off-by: Ming Lei <ming.lei@redhat.com>
Reviewed-by: Uday Shankar <ushankar@purestorage.com>
> ---
> drivers/block/ublk_drv.c | 82 ++++++++++------------------------------
> 1 file changed, 20 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
> index f827c2ef00a9..37a0cb8011c1 100644
> --- a/drivers/block/ublk_drv.c
> +++ b/drivers/block/ublk_drv.c
> @@ -122,15 +122,6 @@ struct ublk_uring_cmd_pdu {
> */
> #define UBLK_IO_FLAG_OWNED_BY_SRV 0x02
>
> -/*
> - * IO command is aborted, so this flag is set in case of
> - * !UBLK_IO_FLAG_ACTIVE.
> - *
> - * After this flag is observed, any pending or new incoming request
> - * associated with this io command will be failed immediately
> - */
> -#define UBLK_IO_FLAG_ABORTED 0x04
> -
> /*
> * UBLK_IO_FLAG_NEED_GET_DATA is set because IO command requires
> * get data buffer address from ublksrv.
> @@ -1083,12 +1074,6 @@ static inline void __ublk_complete_rq(struct request *req)
> unsigned int unmapped_bytes;
> blk_status_t res = BLK_STS_OK;
>
> - /* called from ublk_abort_queue() code path */
> - if (io->flags & UBLK_IO_FLAG_ABORTED) {
> - res = BLK_STS_IOERR;
> - goto exit;
> - }
> -
> /* failed read IO if nothing is read */
> if (!io->res && req_op(req) == REQ_OP_READ)
> io->res = -EIO;
> @@ -1138,47 +1123,6 @@ static void ublk_complete_rq(struct kref *ref)
> __ublk_complete_rq(req);
> }
>
> -static void ublk_do_fail_rq(struct request *req)
> -{
> - struct ublk_queue *ubq = req->mq_hctx->driver_data;
> -
> - if (ublk_nosrv_should_reissue_outstanding(ubq->dev))
> - blk_mq_requeue_request(req, false);
> - else
> - __ublk_complete_rq(req);
> -}
> -
> -static void ublk_fail_rq_fn(struct kref *ref)
> -{
> - struct ublk_rq_data *data = container_of(ref, struct ublk_rq_data,
> - ref);
> - struct request *req = blk_mq_rq_from_pdu(data);
> -
> - ublk_do_fail_rq(req);
> -}
> -
> -/*
> - * Since ublk_rq_task_work_cb always fails requests immediately during
> - * exiting, __ublk_fail_req() is only called from abort context during
> - * exiting. So lock is unnecessary.
> - *
> - * Also aborting may not be started yet, keep in mind that one failed
> - * request may be issued by block layer again.
> - */
> -static void __ublk_fail_req(struct ublk_queue *ubq, struct ublk_io *io,
> - struct request *req)
> -{
> - WARN_ON_ONCE(io->flags & UBLK_IO_FLAG_ACTIVE);
> -
> - if (ublk_need_req_ref(ubq)) {
> - struct ublk_rq_data *data = blk_mq_rq_to_pdu(req);
> -
> - kref_put(&data->ref, ublk_fail_rq_fn);
> - } else {
> - ublk_do_fail_rq(req);
> - }
> -}
> -
> static void ubq_complete_io_cmd(struct ublk_io *io, int res,
> unsigned issue_flags)
> {
> @@ -1670,10 +1614,26 @@ static void ublk_commit_completion(struct ublk_device *ub,
> ublk_put_req_ref(ubq, req);
> }
>
> +static void __ublk_fail_req(struct ublk_queue *ubq, struct ublk_io *io,
> + struct request *req)
> +{
> + WARN_ON_ONCE(io->flags & UBLK_IO_FLAG_ACTIVE);
> +
> + if (ublk_nosrv_should_reissue_outstanding(ubq->dev))
> + blk_mq_requeue_request(req, false);
> + else {
> + io->res = -EIO;
> + __ublk_complete_rq(req);
> + }
> +}
> +
> /*
> - * Called from ubq_daemon context via cancel fn, meantime quiesce ublk
> - * blk-mq queue, so we are called exclusively with blk-mq and ubq_daemon
> - * context, so everything is serialized.
> + * Called from ublk char device release handler, when any uring_cmd is
> + * done, meantime request queue is "quiesced" since all inflight requests
> + * can't be completed because ublk server is dead.
> + *
> + * So no one can hold our request IO reference any more, simply ignore the
> + * reference, and complete the request immediately
> */
> static void ublk_abort_queue(struct ublk_device *ub, struct ublk_queue *ubq)
> {
> @@ -1690,10 +1650,8 @@ static void ublk_abort_queue(struct ublk_device *ub, struct ublk_queue *ubq)
> * will do it
> */
> rq = blk_mq_tag_to_rq(ub->tag_set.tags[ubq->q_id], i);
> - if (rq && blk_mq_request_started(rq)) {
> - io->flags |= UBLK_IO_FLAG_ABORTED;
> + if (rq && blk_mq_request_started(rq))
> __ublk_fail_req(ubq, io, rq);
> - }
> }
> }
> }
> --
> 2.47.0
>
next prev parent reply other threads:[~2025-04-14 20:42 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-14 11:25 [PATCH 0/9] ublk: simplify & improve IO canceling Ming Lei
2025-04-14 11:25 ` [PATCH 1/9] ublk: don't try to stop disk if ->ub_disk is NULL Ming Lei
2025-04-14 19:44 ` Uday Shankar
2025-04-15 1:32 ` Ming Lei
2025-04-14 11:25 ` [PATCH 2/9] ublk: properly serialize all FETCH_REQs Ming Lei
2025-04-14 19:58 ` Uday Shankar
2025-04-14 20:39 ` Jens Axboe
2025-04-14 20:52 ` Uday Shankar
2025-04-14 21:00 ` Jens Axboe
2025-04-15 1:40 ` Ming Lei
2025-04-16 1:13 ` Ming Lei
2025-04-16 1:17 ` Jens Axboe
2025-04-16 2:04 ` Ming Lei
2025-04-16 1:04 ` Uday Shankar
2025-04-14 11:25 ` [PATCH 3/9] ublk: add ublk_force_abort_dev() Ming Lei
2025-04-14 20:06 ` Uday Shankar
2025-04-14 11:25 ` [PATCH 4/9] ublk: rely on ->canceling for dealing with ublk_nosrv_dev_should_queue_io Ming Lei
2025-04-14 20:15 ` Uday Shankar
2025-04-15 1:48 ` Ming Lei
2025-04-14 11:25 ` [PATCH 5/9] ublk: move device reset into ublk_ch_release() Ming Lei
2025-04-14 20:29 ` Uday Shankar
2025-04-15 1:50 ` Ming Lei
2025-04-14 11:25 ` [PATCH 6/9] ublk: improve detection and handling of ublk server exit Ming Lei
2025-04-14 20:36 ` Uday Shankar
2025-04-15 1:54 ` Ming Lei
2025-04-14 11:25 ` [PATCH 7/9] ublk: remove __ublk_quiesce_dev() Ming Lei
2025-04-14 20:37 ` Uday Shankar
2025-04-14 11:25 ` [PATCH 8/9] ublk: simplify aborting ublk request Ming Lei
2025-04-14 20:42 ` Uday Shankar [this message]
2025-04-14 11:25 ` [PATCH 9/9] selftests: ublk: add generic_06 for covering fault inject Ming Lei
2025-04-14 20:44 ` Uday Shankar
2025-04-15 1:57 ` Ming Lei
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=Z/1zK7ycY+iLZBmL@dev-ushankar.dev.purestorage.com \
--to=ushankar@purestorage.com \
--cc=axboe@kernel.dk \
--cc=csander@purestorage.com \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.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.