On 4/8/24 11:16 PM, Jason Wang wrote: >> It turns out only vhost-scsi had an issue where it would send a command >> to the block/LIO layer, wait for a response and then process in the vhost >> task. > Vhost-net TX zerocopy code did the same: > > It sends zerocopy packets to the under layer and waits for the > underlayer. When the DMA is completed, vhost_zerocopy_callback will be > called to schedule vq work for used ring updating. I think it might be slightly different and vhost-net is ok. Above I meant, vhost-scsi would do the equivalent of: vhost_zerocopy_callback -> vhost_net_ubuf_put from vhost_task/thread. For vhost-net then, if we get an early exit via a signal the patches will flush queued works and prevent new ones from being queued. vhost_net_release will run due to the process/thread exit code releasing it's refcounts on the device. vhost_net_release will then do: vhost_net_flush -> vhost_net_ubuf_put_and_wait and wait for vhost_zerocopy_callback -> vhost_net_ubuf_put calls. For vhost-scsi we would hang. We would do our equivalent of vhost_net_ubuf_put from the vhost task/thread. So, when our release function, vhost_scsi_release, is called we will also do a similar wait. However, because the task/thread is killed, we will hang there since the "put" will never be done.
