Re: ublk: Graceful Upgrade of ublk server application

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

Hi Yoav,

On Sun, Apr 20, 2025 at 08:57:23AM +0000, Yoav Cohen wrote:
> Hi Ming,
> 
> Thank you very much!
> The above seems to match our requirements.
> Just to be sure, Do you want me to Implement it and issue a patch or do you plan add it to your plan?

It is great if you'd like to implement the feature, and please add one
selftest case(add quiesce command & one test case) together with the
driver change.

Otherwise, I can add it to my todo list.

Thanks,
Ming

> 
> Thanks
> 
> ________________________________________
> From: Ming Lei <ming.lei@redhat.com>
> Sent: Wednesday, April 16, 2025 12:12 PM
> To: Yoav Cohen
> Cc: Uday Shankar; linux-block@vger.kernel.org; axboe@kernel.dk
> Subject: Re: ublk: Graceful Upgrade of ublk server application
> 
> External email: Use caution opening links or attachments
> 
> 
> 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
> 

-- 
Ming