From: "Michael S. Tsirkin" <mst@redhat.com>
To: Mike Christie <michael.christie@oracle.com>
Cc: Jason Wang <jasowang@redhat.com>,
oleg@redhat.com, ebiederm@xmission.com,
virtualization@lists.linux-foundation.org, sgarzare@redhat.com,
stefanha@redhat.com, brauner@kernel.org,
Laurent Vivier <lvivier@redhat.com>
Subject: Re: [PATCH 0/9] vhost: Support SIGKILL by flushing and exiting
Date: Tue, 9 Apr 2024 12:40:11 -0400 [thread overview]
Message-ID: <20240409110947-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <7044bd8c-99a9-4da8-a5ab-c2c293cdea40@oracle.com>
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
next prev parent reply other threads:[~2024-04-09 16:40 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-16 0:46 [PATCH 0/9] vhost: Support SIGKILL by flushing and exiting Mike Christie
2024-03-16 0:46 ` [PATCH 1/9] vhost-scsi: Handle vhost_vq_work_queue failures for events Mike Christie
2024-03-16 0:47 ` [PATCH 2/9] vhost-scsi: Handle vhost_vq_work_queue failures for cmds Mike Christie
2024-03-16 0:47 ` [PATCH 3/9] vhost-scsi: Use system wq to flush dev for TMFs Mike Christie
2024-03-16 0:47 ` [PATCH 4/9] vhost: Remove vhost_vq_flush Mike Christie
2024-03-16 0:47 ` [PATCH 5/9] vhost_scsi: Handle vhost_vq_work_queue failures for TMFs Mike Christie
2024-03-16 0:47 ` [PATCH 6/9] vhost: Use virtqueue mutex for swapping worker Mike Christie
2024-03-16 0:47 ` [PATCH 7/9] vhost: Release worker mutex during flushes Mike Christie
2024-03-16 0:47 ` [PATCH 8/9] vhost_task: Handle SIGKILL by flushing work and exiting Mike Christie
2024-03-16 0:47 ` [PATCH 9/9] kernel: Remove signal hacks for vhost_tasks Mike Christie
2024-04-09 4:16 ` [PATCH 0/9] vhost: Support SIGKILL by flushing and exiting Jason Wang
2024-04-09 14:57 ` Mike Christie
2024-04-09 16:40 ` Michael S. Tsirkin [this message]
2024-04-09 21:55 ` michael.christie
2024-04-10 4:21 ` Michael S. Tsirkin
2024-04-18 7:10 ` Michael S. Tsirkin
2024-04-11 8:39 ` Jason Wang
2024-04-11 16:19 ` Mike Christie
2024-04-12 3:28 ` Jason Wang
2024-04-12 16:52 ` michael.christie
2024-04-15 8:52 ` Jason Wang
2024-04-17 3:50 ` Jason Wang
2024-04-17 16:03 ` Mike Christie
2024-04-18 4:08 ` Jason Wang
2024-04-18 7:07 ` Michael S. Tsirkin
2024-04-18 9:25 ` Andreas Karis
2024-04-19 0:37 ` Jason Wang
2024-04-19 0:40 ` Jason Wang
2024-05-15 6:27 ` Jason Wang
2024-05-15 7:24 ` Michael S. Tsirkin
2024-04-19 0:33 ` Jason Wang
2024-04-18 7:01 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240409110947-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=brauner@kernel.org \
--cc=ebiederm@xmission.com \
--cc=jasowang@redhat.com \
--cc=lvivier@redhat.com \
--cc=michael.christie@oracle.com \
--cc=oleg@redhat.com \
--cc=sgarzare@redhat.com \
--cc=stefanha@redhat.com \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.