From: Randy Dunlap <rdunlap@infradead.org>
To: Josef Bacik <josef@toxicpanda.com>,
Ming Lei <tom.leiming@gmail.com>, Jens Axboe <axboe@kernel.dk>,
Caleb Sander Mateos <csander@purestorage.com>
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org
Subject: Re: [PATCH 9/9] ublk: refuse to go live over canceled io commands
Date: Mon, 28 Sep 2026 10:35:14 -0700 [thread overview]
Message-ID: <453fa7f6-dbbb-4023-b1ad-ccd6d746a138@infradead.org> (raw)
In-Reply-To: <20260928-b4-ublk-cancel-stop-v1-9-4a4360232a46@toxicpanda.com>
Hi,
On 9/28/26 9:00 AM, Josef Bacik wrote:
> diff --git a/Documentation/block/ublk.rst b/Documentation/block/ublk.rst
> index 28300fee22bf..05d702f66a93 100644
> --- a/Documentation/block/ublk.rst
> +++ b/Documentation/block/ublk.rst
> @@ -118,7 +118,13 @@ managing and controlling ublk devices with help of several control commands:
> After the server prepares userspace resources (such as creating I/O handler
> threads & io_uring for handling ublk IO), this command is sent to the
> driver for allocating & exposing ``/dev/ublkb*``. Parameters set via
> - ``UBLK_CMD_SET_PARAMS`` are applied for creating the device.
> + ``UBLK_CMD_SET_PARAMS`` are applied for creating the device. The command
> + fails with ``-ENODEV`` if any fetched io command got canceled meantime,
IO or I/O
command was canceled
> + by ``UBLK_CMD_STOP_DEV`` or because its io_uring is gone, and the device
> + has to be deleted then. With ``UBLK_F_BATCH_IO`` it fails the same way
> + after a ``UBLK_CMD_STOP_DEV`` sent while no process had ``/dev/ublkc*``
> + open, or after the current one opened it, even if no io command had
IO or I/O
> + been fetched yet.
>
> - ``UBLK_CMD_STOP_DEV``
>
> @@ -195,7 +201,12 @@ managing and controlling ublk devices with help of several control commands:
> command is accepted after ublk device is quiesced and a new process has
> opened ``/dev/ublkc*`` and get all ublk queues be ready. When this command
> returns, ublk device is unquiesced and new I/O requests are passed to the
> - new process.
> + new process. It fails with ``-ENODEV`` if any of the new io commands got
IO or I/O
commands was
> + canceled already, and with ``UBLK_F_BATCH_IO`` also if the cancel of a
> + ``UBLK_CMD_QUIESCE_DEV`` reached one of its queues after the old process
> + released ``/dev/ublkc*`` and before that queue got ready. The device has
was ready.
> + to be deleted then, or the recovery
> + started over after the new process has closed ``/dev/ublkc*``.
>
> - user recovery feature description
>
--
~Randy
next prev parent reply other threads:[~2026-09-28 17:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 16:00 [PATCH 0/9] ublk: fix dispatch to canceled io commands Josef Bacik
2026-09-28 16:00 ` [PATCH 1/9] ublk: keep queue canceling over canceled commands Josef Bacik
2026-09-28 16:46 ` Caleb Sander Mateos
2026-09-28 18:34 ` Josef Bacik
2026-09-28 16:00 ` [PATCH 2/9] ublk: clear ub->canceling with the queue's own flag Josef Bacik
2026-09-28 16:00 ` [PATCH 3/9] ublk: publish io->cmd under io->lock in the commit paths Josef Bacik
2026-09-28 17:53 ` Caleb Sander Mateos
2026-09-29 13:06 ` Josef Bacik
2026-09-28 16:00 ` [PATCH 4/9] ublk: read the io under io->lock in ublk_cancel_cmd() Josef Bacik
2026-09-28 16:00 ` [PATCH 5/9] ublk: complete a command canceled before it was marked from its issuer Josef Bacik
2026-09-28 16:00 ` [PATCH 6/9] ublk: split ublk_claim_cmd() out of ublk_cancel_cmd() Josef Bacik
2026-09-28 16:00 ` [PATCH 7/9] ublk: mark queues and command in one cancel_mutex hold Josef Bacik
2026-09-28 16:00 ` [PATCH 8/9] ublk: claim commands under ub->mutex in ublk_stop_dev() Josef Bacik
2026-09-28 16:00 ` [PATCH 9/9] ublk: refuse to go live over canceled io commands Josef Bacik
2026-09-28 17:35 ` Randy Dunlap [this message]
2026-09-29 14:44 ` [PATCH 0/9] ublk: fix dispatch to " Ming Lei
2026-09-30 14:17 ` Josef Bacik
2026-09-30 16:40 ` 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=453fa7f6-dbbb-4023-b1ad-ccd6d746a138@infradead.org \
--to=rdunlap@infradead.org \
--cc=axboe@kernel.dk \
--cc=csander@purestorage.com \
--cc=josef@toxicpanda.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tom.leiming@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