From: "Eric W. Biederman" <ebiederm@xmission.com>
To: Mike Christie <michael.christie@oracle.com>
Cc: axboe@kernel.dk, Christian Brauner <brauner@kernel.org>,
mst@redhat.com, linux-kernel@vger.kernel.org, oleg@redhat.com,
linux@leemhuis.info, stefanha@redhat.com,
nicolas.dichtel@6wind.com,
virtualization@lists.linux-foundation.org,
torvalds@linux-foundation.org
Subject: Re: [RFC PATCH 5/8] vhost: Add callback that stops new work and waits on running ones
Date: Thu, 18 May 2023 13:38:29 -0500 [thread overview]
Message-ID: <87ttw9fpsq.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <81e1a94d-531a-2e43-baee-da4b35644e87@oracle.com> (Mike Christie's message of "Thu, 18 May 2023 10:03:32 -0500")
Mike Christie <michael.christie@oracle.com> writes:
> On 5/18/23 9:18 AM, Christian Brauner wrote:
>>> @@ -352,12 +353,13 @@ static int vhost_worker(void *data)
>>> if (!node) {
>>> schedule();
>>> /*
>>> - * When we get a SIGKILL our release function will
>>> - * be called. That will stop new IOs from being queued
>>> - * and check for outstanding cmd responses. It will then
>>> - * call vhost_task_stop to exit us.
>>> + * When we get a SIGKILL we kick off a work to
>>> + * run the driver's helper to stop new work and
>>> + * handle completions. When they are done they will
>>> + * call vhost_task_stop to tell us to exit.
>>> */
>>> - vhost_task_get_signal();
>>> + if (vhost_task_get_signal())
>>> + schedule_work(&dev->destroy_worker);
>>> }
>>
>> I'm pretty sure you still need to actually call exit here. Basically
>> mirror what's done in io_worker_exit() minus the io specific bits.
>
> We do call do_exit(). Once destory_worker has flushed the device and
> all outstanding IO has completed it call vhost_task_stop(). vhost_worker()
> above then breaks out of the loop and returns and vhost_task_fn() does
> do_exit().
I am not certain how you want to structure this but you really should
not call get_signal after it returns positive before you call do_exit.
You are in complete uncharted and untested waters calling get_signal
multiple times, when get_signal figures the proper response is to
call do_exit itself.
Eric
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2023-05-18 18:38 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-18 0:09 [RFC PATCH 0/8] vhost_tasks: Use CLONE_THREAD/SIGHAND Mike Christie
2023-05-18 0:09 ` [RFC PATCH 1/8] signal: Dequeue SIGKILL even if SIGNAL_GROUP_EXIT/group_exec_task is set Mike Christie
2023-05-18 2:34 ` Eric W. Biederman
2023-05-18 3:49 ` Eric W. Biederman
2023-05-18 15:21 ` Mike Christie
2023-05-18 16:25 ` Oleg Nesterov
2023-05-18 16:42 ` Mike Christie
2023-05-18 17:04 ` Oleg Nesterov
2023-05-18 18:28 ` Eric W. Biederman
2023-05-18 22:57 ` Mike Christie
2023-05-19 4:16 ` Eric W. Biederman
2023-05-19 23:24 ` Mike Christie
2023-05-22 13:30 ` Oleg Nesterov
[not found] ` <20230518-kontakt-geduckt-25bab595f503@brauner>
2023-05-18 15:27 ` Mike Christie
[not found] ` <20230518-ratgeber-erbeben-843e68b0d6ac@brauner>
2023-05-18 18:08 ` Oleg Nesterov
[not found] ` <20230518-fettgehalt-erdbeben-25587a432815@brauner>
2023-05-18 18:23 ` Oleg Nesterov
2023-05-18 0:09 ` [RFC PATCH 2/8] vhost/vhost_task: Hook vhost layer into signal handler Mike Christie
2023-05-18 0:16 ` Linus Torvalds
2023-05-18 1:01 ` Mike Christie
2023-05-18 0:09 ` [RFC PATCH 3/8] fork/vhost_task: Switch to CLONE_THREAD and CLONE_SIGHAND Mike Christie
2023-05-18 0:09 ` [RFC PATCH 4/8] vhost-net: Move vhost_net_open Mike Christie
2023-05-18 0:09 ` [RFC PATCH 5/8] vhost: Add callback that stops new work and waits on running ones Mike Christie
[not found] ` <20230518-lokomotive-aufziehen-dbc432136b76@brauner>
2023-05-18 15:03 ` Mike Christie
2023-05-18 18:38 ` Eric W. Biederman [this message]
2023-05-18 0:09 ` [RFC PATCH 6/8] vhost-scsi: Add callback to stop and wait on works Mike Christie
2023-05-18 0:09 ` [RFC PATCH 7/8] vhost-net: " Mike Christie
2023-05-18 0:09 ` [RFC PATCH 8/8] fork/vhost_task: remove no_files Mike Christie
2023-05-18 1:04 ` Mike Christie
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=87ttw9fpsq.fsf@email.froward.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@leemhuis.info \
--cc=michael.christie@oracle.com \
--cc=mst@redhat.com \
--cc=nicolas.dichtel@6wind.com \
--cc=oleg@redhat.com \
--cc=stefanha@redhat.com \
--cc=torvalds@linux-foundation.org \
--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 NNTP newsgroup(s).