On Tue, Apr 09, 2024 at 09:57:00AM -0500, Mike Christie wrote: > 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. If you can find a way to cancel them instead of flushing out, I think it would be better for net, too. -- MST
