From: Mike Christie <michael.christie@oracle.com>
To: oleg@redhat.com, ebiederm@xmission.com,
virtualization@lists.linux-foundation.org, mst@redhat.com,
sgarzare@redhat.com, jasowang@redhat.com, stefanha@redhat.com,
brauner@kernel.org
Subject: [PATCH 0/9] vhost: Support SIGKILL by flushing and exiting
Date: Fri, 15 Mar 2024 19:46:58 -0500 [thread overview]
Message-ID: <20240316004707.45557-1-michael.christie@oracle.com> (raw)
The following patches were made over Linus's tree and also apply over
mst's vhost branch. The patches add the ability for vhost_tasks to
handle SIGKILL by flushing queued works, stop new works from being
queued, and prepare the task for an early exit.
This removes the need for the signal/coredump hacks added in:
Commit f9010dbdce91 ("fork, vhost: Use CLONE_THREAD to fix freezer/ps regression")
when the vhost_task patches were initially merged and fix the issue
in this thread:
https://lore.kernel.org/all/000000000000a41b82060e875721@google.com/
Long Background:
The original vhost worker code didn't support any signals. If the
userspace application that owned the worker got a SIGKILL, the app/
process would exit dropping all references to the device and then the
file operation's release function would be called. From there we would
wait on running IO then cleanup the device's memory.
When we switched to vhost_tasks being a thread in the owner's process we
added some hacks to the signal/coredump code so we could continue to
wait on running IO and process it from the vhost_task. The idea was that
we would eventually remove the hacks. We recently hit this bug:
https://lore.kernel.org/all/000000000000a41b82060e875721@google.com/
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. So patches 1-5 prepares vhost-scsi to handle when the vhost_task
is killed while we still have commands outstanding. The next patches then
prepare and convert the vhost and vhost_task layers to handle SIGKILL
by flushing running works, marking the vhost_task as dead so there's
no future uses, then exiting.
next reply other threads:[~2024-03-16 0:47 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-16 0:46 Mike Christie [this message]
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
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=20240316004707.45557-1-michael.christie@oracle.com \
--to=michael.christie@oracle.com \
--cc=brauner@kernel.org \
--cc=ebiederm@xmission.com \
--cc=jasowang@redhat.com \
--cc=mst@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).