public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Uday Shankar <ushankar@purestorage.com>,
	Ming Lei <ming.lei@redhat.com>,
	"zhang, the-essence-of-life" <zhangweize9@gmail.com>,
	Caleb Sander Mateos <csander@purestorage.com>,
	Jens Axboe <axboe@kernel.dk>, Shuah Khan <shuah@kernel.org>
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v2 1/2] ublk: reset per-IO canceled flag on each fetch
Date: Mon, 6 Apr 2026 09:22:13 +0200	[thread overview]
Message-ID: <53aec093-5494-4b4b-a103-bc166381f236@suse.de> (raw)
In-Reply-To: <20260405-cancel-v2-1-02d711e643c2@purestorage.com>

On 4/6/26 06:25, Uday Shankar wrote:
> If a ublk server starts recovering devices but dies before issuing fetch
> commands for all IOs, cancellation of the fetch commands that were
> successfully issued may never complete. This is because the per-IO
> canceled flag can remain set even after the fetch for that IO has been
> submitted - the per-IO canceled flags for all IOs in a queue are reset
> together only once all IOs for that queue have been fetched. So if a
> nonempty proper subset of the IOs for a queue are fetched when the ublk
> server dies, the IOs in that subset will never successfully be canceled,
> as their canceled flags remain set, and this prevents ublk_cancel_cmd
> from actually calling io_uring_cmd_done on the commands, despite the
> fact that they are outstanding.
> 
> Fix this by resetting the per-IO cancel flags immediately when each IO
> is fetched instead of waiting for all IOs for the queue (which may never
> happen).
> 
> Signed-off-by: Uday Shankar <ushankar@purestorage.com>
> Fixes: 728cbac5fe21 ("ublk: move device reset into ublk_ch_release()")
> Reviewed-by: Ming Lei <ming.lei@redhat.com>
> Reviewed-by: zhang, the-essence-of-life <zhangweize9@gmail.com>
> ---
>   drivers/block/ublk_drv.c | 21 +++++++++++++--------
>   1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
> index 3ba7da94d31499590a06a8b307ed151919a027cb..92dabeb820344107c9fadfae94396082b933d84e 100644
> --- a/drivers/block/ublk_drv.c
> +++ b/drivers/block/ublk_drv.c
> @@ -2916,22 +2916,26 @@ static void ublk_stop_dev(struct ublk_device *ub)
>   	ublk_cancel_dev(ub);
>   }
>   
> +static void ublk_reset_io_flags(struct ublk_queue *ubq, struct ublk_io *io)
> +{
> +	/* UBLK_IO_FLAG_CANCELED can be cleared now */
> +	spin_lock(&ubq->cancel_lock);
> +	io->flags &= ~UBLK_IO_FLAG_CANCELED;
> +	spin_unlock(&ubq->cancel_lock);
> +}
> +
One wonders why we can't use 'set_bit' here, or, rather,
convert 'flags' usage to set_bit().
The spinlock feels a bit silly as it's now per-io, and one would think
that we don't have concurrent accesses to the same io...

>   /* reset per-queue io flags */
>   static void ublk_queue_reset_io_flags(struct ublk_queue *ubq)
>   {
> -	int j;
> -
> -	/* UBLK_IO_FLAG_CANCELED can be cleared now */
>   	spin_lock(&ubq->cancel_lock);
> -	for (j = 0; j < ubq->q_depth; j++)
> -		ubq->ios[j].flags &= ~UBLK_IO_FLAG_CANCELED;
>   	ubq->canceling = false;
>   	spin_unlock(&ubq->cancel_lock);
>   	ubq->fail_io = false;
>   }
Similar here; as we don't loop anymore, why do we need the spinlock?
Isn't WRITE_ONCE() sufficient here?

>   
>   /* device can only be started after all IOs are ready */
> -static void ublk_mark_io_ready(struct ublk_device *ub, u16 q_id)
> +static void ublk_mark_io_ready(struct ublk_device *ub, u16 q_id,
> +	struct ublk_io *io)
>   	__must_hold(&ub->mutex)
>   {
>   	struct ublk_queue *ubq = ublk_get_queue(ub, q_id);
> @@ -2940,6 +2944,7 @@ static void ublk_mark_io_ready(struct ublk_device *ub, u16 q_id)
>   		ub->unprivileged_daemons = true;
>   
>   	ubq->nr_io_ready++;
> +	ublk_reset_io_flags(ubq, io);
>   
>   	/* Check if this specific queue is now fully ready */
>   	if (ublk_queue_ready(ubq)) {
> @@ -3202,7 +3207,7 @@ static int ublk_fetch(struct io_uring_cmd *cmd, struct ublk_device *ub,
>   	if (!ret)
>   		ret = ublk_config_io_buf(ub, io, cmd, buf_addr, NULL);
>   	if (!ret)
> -		ublk_mark_io_ready(ub, q_id);
> +		ublk_mark_io_ready(ub, q_id, io);
>   	mutex_unlock(&ub->mutex);
>   	return ret;
>   }
> @@ -3610,7 +3615,7 @@ static int ublk_batch_prep_io(struct ublk_queue *ubq,
>   	ublk_io_unlock(io);
>   
>   	if (!ret)
> -		ublk_mark_io_ready(data->ub, ubq->q_id);
> +		ublk_mark_io_ready(data->ub, ubq->q_id, io);
>   
>   	return ret;
>   }
> 

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich

  reply	other threads:[~2026-04-06  7:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-06  4:25 [PATCH v2 0/2] ublk: fix infinite loop in ublk server teardown Uday Shankar
2026-04-06  4:25 ` [PATCH v2 1/2] ublk: reset per-IO canceled flag on each fetch Uday Shankar
2026-04-06  7:22   ` Hannes Reinecke [this message]
2026-04-06 11:18     ` Ming Lei
2026-04-06  4:25 ` [PATCH v2 2/2] selftests: ublk: test that teardown after incomplete recovery completes Uday Shankar
2026-04-06 14:19   ` Ming Lei
2026-04-06 14:38 ` [PATCH v2 0/2] ublk: fix infinite loop in ublk server teardown Jens Axboe

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=53aec093-5494-4b4b-a103-bc166381f236@suse.de \
    --to=hare@suse.de \
    --cc=axboe@kernel.dk \
    --cc=csander@purestorage.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    --cc=shuah@kernel.org \
    --cc=ushankar@purestorage.com \
    --cc=zhangweize9@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox