* [PATCH 1/2] ublk: cancel device on START_DEV failure [not found] <20260112041209.79445-1-ming.lei@redhat.com> @ 2026-01-12 4:12 ` Ming Lei 2026-01-12 16:52 ` Caleb Sander Mateos 0 siblings, 1 reply; 3+ messages in thread From: Ming Lei @ 2026-01-12 4:12 UTC (permalink / raw) To: Jens Axboe, linux-block Cc: Caleb Sander Mateos, Uday Shankar, Seamus Connor, Ming Lei, stable When ublk_ctrl_start_dev() fails after waiting for completion, the device needs to be properly cancelled to prevent leaving it in an inconsistent state. Without this, pending I/O commands may remain uncompleted and the device cannot be cleanly removed. Add ublk_cancel_dev() call in the error path to ensure proper cleanup when START_DEV fails. Cc: <stable@vger.kernel.org> Signed-off-by: Ming Lei <ming.lei@redhat.com> --- drivers/block/ublk_drv.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c index f6e5a0766721..2d6250d61a7b 100644 --- a/drivers/block/ublk_drv.c +++ b/drivers/block/ublk_drv.c @@ -2953,8 +2953,10 @@ static int ublk_ctrl_start_dev(struct ublk_device *ub, if (wait_for_completion_interruptible(&ub->completion) != 0) return -EINTR; - if (ub->ublksrv_tgid != ublksrv_pid) - return -EINVAL; + if (ub->ublksrv_tgid != ublksrv_pid) { + ret = -EINVAL; + goto out; + } mutex_lock(&ub->mutex); if (ub->dev_info.state == UBLK_S_DEV_LIVE || @@ -3017,6 +3019,9 @@ static int ublk_ctrl_start_dev(struct ublk_device *ub, put_disk(disk); out_unlock: mutex_unlock(&ub->mutex); +out: + if (ret) + ublk_cancel_dev(ub); return ret; } -- 2.47.0 ^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH 1/2] ublk: cancel device on START_DEV failure 2026-01-12 4:12 ` [PATCH 1/2] ublk: cancel device on START_DEV failure Ming Lei @ 2026-01-12 16:52 ` Caleb Sander Mateos 2026-01-13 1:38 ` Ming Lei 0 siblings, 1 reply; 3+ messages in thread From: Caleb Sander Mateos @ 2026-01-12 16:52 UTC (permalink / raw) To: Ming Lei; +Cc: Jens Axboe, linux-block, Uday Shankar, Seamus Connor, stable On Sun, Jan 11, 2026 at 8:12 PM Ming Lei <ming.lei@redhat.com> wrote: > > When ublk_ctrl_start_dev() fails after waiting for completion, the > device needs to be properly cancelled to prevent leaving it in an > inconsistent state. Without this, pending I/O commands may remain > uncompleted and the device cannot be cleanly removed. > > Add ublk_cancel_dev() call in the error path to ensure proper cleanup > when START_DEV fails. It's not clear to me why the UBLK_IO_FETCH_REQ commands must be cancelled if UBLK_CMD_START_DEV fails. Wouldn't they get cancelled whenever the ublk device is deleted or the ublk server exits? And this seems like a UAPI change. Previously, the ublk server could issue UBLK_CMD_START_DEV again if it failed, but now it must also resubmit all the UBLK_IO_FETCH_REQ commands. This also means that issuing UBLK_CMD_START_DEV after the ublk device has already been started behaves like UBLK_CMD_STOP_DEV, which seems highly unintuitive. Best, Caleb > > Cc: <stable@vger.kernel.org> > Signed-off-by: Ming Lei <ming.lei@redhat.com> > --- > drivers/block/ublk_drv.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c > index f6e5a0766721..2d6250d61a7b 100644 > --- a/drivers/block/ublk_drv.c > +++ b/drivers/block/ublk_drv.c > @@ -2953,8 +2953,10 @@ static int ublk_ctrl_start_dev(struct ublk_device *ub, > if (wait_for_completion_interruptible(&ub->completion) != 0) > return -EINTR; > > - if (ub->ublksrv_tgid != ublksrv_pid) > - return -EINVAL; > + if (ub->ublksrv_tgid != ublksrv_pid) { > + ret = -EINVAL; > + goto out; > + } > > mutex_lock(&ub->mutex); > if (ub->dev_info.state == UBLK_S_DEV_LIVE || > @@ -3017,6 +3019,9 @@ static int ublk_ctrl_start_dev(struct ublk_device *ub, > put_disk(disk); > out_unlock: > mutex_unlock(&ub->mutex); > +out: > + if (ret) > + ublk_cancel_dev(ub); > return ret; > } > > -- > 2.47.0 > ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH 1/2] ublk: cancel device on START_DEV failure 2026-01-12 16:52 ` Caleb Sander Mateos @ 2026-01-13 1:38 ` Ming Lei 0 siblings, 0 replies; 3+ messages in thread From: Ming Lei @ 2026-01-13 1:38 UTC (permalink / raw) To: Caleb Sander Mateos Cc: Jens Axboe, linux-block, Uday Shankar, Seamus Connor, stable On Mon, Jan 12, 2026 at 08:52:31AM -0800, Caleb Sander Mateos wrote: > On Sun, Jan 11, 2026 at 8:12 PM Ming Lei <ming.lei@redhat.com> wrote: > > > > When ublk_ctrl_start_dev() fails after waiting for completion, the > > device needs to be properly cancelled to prevent leaving it in an > > inconsistent state. Without this, pending I/O commands may remain > > uncompleted and the device cannot be cleanly removed. > > > > Add ublk_cancel_dev() call in the error path to ensure proper cleanup > > when START_DEV fails. > > It's not clear to me why the UBLK_IO_FETCH_REQ commands must be > cancelled if UBLK_CMD_START_DEV fails. Wouldn't they get cancelled > whenever the ublk device is deleted or the ublk server exits? Good catch, DEL_DEV/STOP_DEV supposes to be capable of handling irrecoverable START_DEV failure. So this patch isn't needed. Thanks, Ming ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-01-13 1:38 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20260112041209.79445-1-ming.lei@redhat.com>
2026-01-12 4:12 ` [PATCH 1/2] ublk: cancel device on START_DEV failure Ming Lei
2026-01-12 16:52 ` Caleb Sander Mateos
2026-01-13 1:38 ` Ming Lei
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox