Re: [PATCH] ublk: wait on ublk_dev_ready() instead of ub->completion

On Sun, 19 Jul 2026 08:45:40 -0500, Ming Lei wrote:
> ub->completion is only re-armed by a successful START_USER_RECOVERY. If
> the ublk server sends END_USER_RECOVERY without one - e.g. its START
> failed with -EBUSY and the error was ignored - the wait is satisfied by
> the stale completion of the previous recovery cycle, and the device is
> marked LIVE and the requeue list kicked while the FETCH stream is still
> running and ubq->canceling is still set. The kick redispatches a
> previously requeued request, __ublk_queue_rq_common() sees ->canceling
> and parks it again via __ublk_abort_rq(), and after the last FETCH
> clears ->canceling nothing ever kicks the requeue list again: the
> request is stranded there while holding its tag. If it is the flush
> machinery's flush_rq, every subsequent fsync piles up in uninterruptible
> sleep and teardown hangs on tag draining. This matches a report of a
> lost PREFLUSH with ext4 on top of ublk after daemon crash recovery.
> 
> [...]

Applied, thanks!

[1/1] ublk: wait on ublk_dev_ready() instead of ub->completion
      commit: 432a9b2780c0a01caf547bd1fc2fcf28aeb8d173

Best regards,
-- 
Jens Axboe