Re: ublk: Graceful Upgrade of ublk server application

[Ming Lei <ming.lei@redhat.com>]

On Wed, Apr 16, 2025 at 08:16:44AM +0000, Yoav Cohen wrote:
> Hi,
> 
> The use case is as you say to replace the binary (update) without making the bdev to disappear.
> Currently I don't even use the user_copy(to avoid the 1 more system call) so the io buffer is also part of the sqe which is prevent me from free it from userspace perspective.
> So yes, even ABORT_URING_CMD by given tag can be enough.
> What do you think?

I think the requirement is reasonable, which could be one QUIESCE_DEV command:

- only usable for UBLK_F_USER_RECOVERY

- need ublk server cooperation for handling inflight IO command

- fallback to normal cancel code path in case that io_uring is exiting

The implementation shouldn't be hard:

- mark ubq->canceling as ture 
	- freeze request queue
	- mark ubq->canceling as true
	- unfreeze request queue

- canceling all uring_cmd with UBLK_IO_RES_ABORT (*)
	- now there can't be new ublk IO request coming, and ublk server won't
	send new uring_cmd too, 

	- the gatekeeper code of __ublk_ch_uring_cmd() should be reliable to prevent
	any new uring_cmd from malicious application, maybe need audit & refactoring
	a bit

	- need ublk server to handle UBLK_IO_RES_ABORT correctly: release all
	  kinds resource, close ublk char device...

- wait until ublk char device is released by checking UB_STATE_OPEN

- now ublk state becomes UBLK_S_DEV_QUIESCED or UBLK_S_DEV_FAIL_IO,
and userspace can replace the binary and recover device with new
application via UBLK_CMD_START_USER_RECOVERY & UBLK_CMD_END_USER_RECOVERY

Please let us know if the above works for your requirement.

Thanks,
Ming