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; }
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
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
linux-stable-mirror@lists.linaro.org
-
Caleb Sander Mateos -
Ming Lei