On Fri, Sep 23, 2022 at 02:15:02PM +0800, ZiyangZhang wrote: > With USER_RECOVERY feature enabled, the monitor_work schedules > quiesce_work after finding a dying ubq_daemon. The monitor_work > should also abort all rqs issued to userspace before the ubq_daemon is > dying. The quiesce_work's job is to: > (1) quiesce request queue. > (2) check if there is any INFLIGHT rq. If so, we retry until all these > rqs are requeued and become IDLE. These rqs should be requeued by > ublk_queue_rq(), task work, io_uring fallback wq or monitor_work. > (3) complete all ioucmds by calling io_uring_cmd_done(). We are safe to > do so because no ioucmd can be referenced now. > (5) set ub's state to UBLK_S_DEV_QUIESCED, which means we are ready for > recovery. This state is exposed to userspace by GET_DEV_INFO. > > The driver can always handle STOP_DEV and cleanup everything no matter > ub's state is LIVE or QUIESCED. After ub's state is UBLK_S_DEV_QUIESCED, > user can recover with new process. > > Note: we do not change the default behavior with reocvery feature > disabled. monitor_work still schedules stop_work and abort inflight > rqs. And finally ublk_device is released. > > Signed-off-by: ZiyangZhang <ZiyangZhang@xxxxxxxxxxxxxxxxx> Looks fine, Reviewed-by: Ming Lei <ming.lei@xxxxxxxxxx> Thanks, Ming