On 2020-09-21 11:23, Mike Christie wrote:> We might not do the final se_cmd put from vhost_scsi_complete_cmd_work. > If the last put happens a little later then we could race where > vhost_scsi_complete_cmd_work does vhost_signal, the guest runs and sends > more IO, and vhost_scsi_handle_vq runs but does not find any free cmds. > > This patch has us delay completing the cmd until the last lio core ref > is dropped. We then know that once we signal to the guest that the cmd > is completed that if it queues a new command it will find a free cmd.It seems weird to me to see a reference to LIO in the description of a vhost patch? Since this driver supports more backends than LIO, shouldn't the patch description be made more generic? Thanks, Bart.
On 2020-09-21 19:48, Bart Van Assche wrote:> On 2020-09-21 11:23, Mike Christie wrote: >> We might not do the final se_cmd put from vhost_scsi_complete_cmd_work. >> If the last put happens a little later then we could race where >> vhost_scsi_complete_cmd_work does vhost_signal, the guest runs and sends >> more IO, and vhost_scsi_handle_vq runs but does not find any free cmds. >> >> This patch has us delay completing the cmd until the last lio core ref >> is dropped. We then know that once we signal to the guest that the cmd >> is completed that if it queues a new command it will find a free cmd. > > It seems weird to me to see a reference to LIO in the description of a > vhost patch? Since this driver supports more backends than LIO, shouldn't > the patch description be made more generic?Please ignore the above comment. Bart.