From: Sean Christopherson <seanjc@google.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Jason Wang <jasowang@redhat.com>,
kvm@vger.kernel.org, virtualization@lists.linux.dev,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: Re: [PATCH 1/3] vhost_task: KVM: Don't wake KVM x86's recovery thread if vhost task was killed
Date: Tue, 26 Aug 2025 07:03:33 -0700 [thread overview]
Message-ID: <aK2-tQLL-WN7Mqpb@google.com> (raw)
In-Reply-To: <20250826034937-mutt-send-email-mst@kernel.org>
On Tue, Aug 26, 2025, Michael S. Tsirkin wrote:
> On Mon, Aug 25, 2025 at 05:40:09PM -0700, Sean Christopherson wrote:
> > Provide an API in vhost task instead of forcing KVM to solve the problem,
> > as KVM would literally just add an equivalent to VHOST_TASK_FLAGS_KILLED,
> > along with a new lock to protect said flag. In general, forcing simple
> > usage of vhost task to care about signals _and_ take non-trivial action to
> > do the right thing isn't developer friendly, and is likely to lead to
> > similar bugs in the future.
> >
> > Debugged-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > Link: https://lore.kernel.org/all/aKkLEtoDXKxAAWju@google.com
> > Link: https://lore.kernel.org/all/aJ_vEP2EHj6l0xRT@google.com
> > Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > Fixes: d96c77bd4eeb ("KVM: x86: switch hugepage recovery thread to vhost_task")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Sean Christopherson <seanjc@google.com>
>
> OK but I dislike the API.
FWIW, I don't love it either.
> Default APIs should be safe. So vhost_task_wake_safe should be
> vhost_task_wake
>
> This also reduces the changes to kvm.
>
>
> It does not look like we need the "unsafe" variant, so pls drop it.
vhost_vq_work_queue() calls
vhost_worker_queue()
|
-> worker->ops->wakeup(worker)
|
-> vhost_task_wakeup()
|
-> vhost_task_wake()
while holding RCU and so can't sleep.
rcu_read_lock();
worker = rcu_dereference(vq->worker);
if (worker) {
queued = true;
vhost_worker_queue(worker, work);
}
rcu_read_unlock();
And the call from __vhost_worker_flush() is done while holding a vhost_worker.mutex.
That's probably ok? But there are many paths that lead to __vhost_worker_flush(),
which makes it difficult to audit all flows. So even if there is an easy change
for the RCU conflict, I wouldn't be comfortable adding a mutex_lock() to so many
flows in a patch that needs to go to stable@.
> If we do need it, it should be called __vhost_task_wake.
I initially had that, but didn't like that vhost_task_wake() wouldn't call
__vhost_task_wake(), i.e. wouldn't follow the semi-standard pattern of the
no-underscores function being a wrapper for the double-underscores function.
I'm definitely not opposed to that though (or any other naming options). Sans
comments, this was my other idea for names:
static void ____vhost_task_wake(struct vhost_task *vtsk)
{
wake_up_process(vtsk->task);
}
void __vhost_task_wake(struct vhost_task *vtsk)
{
WARN_ON_ONCE(!vtsk->handle_sigkill);
if (WARN_ON_ONCE(test_bit(VHOST_TASK_FLAGS_KILLED, &vtsk->flags)))
return;
____vhost_task_wake(vtsk);
}
EXPORT_SYMBOL_GPL(__vhost_task_wake);
void vhost_task_wake(struct vhost_task *vtsk)
{
guard(mutex)(&vtsk->exit_mutex);
if (WARN_ON_ONCE(test_bit(VHOST_TASK_FLAGS_STOP, &vtsk->flags)))
return;
if (test_bit(VHOST_TASK_FLAGS_KILLED, &vtsk->flags))
return;
____vhost_task_wake(vtsk);
}
EXPORT_SYMBOL_GPL(vhost_task_wake);
next prev parent reply other threads:[~2025-08-26 14:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-26 0:40 [PATCH 0/3] vhost_task: KVM: Fix a race where KVM wakes an exited task Sean Christopherson
2025-08-26 0:40 ` [PATCH 1/3] vhost_task: KVM: Don't wake KVM x86's recovery thread if vhost task was killed Sean Christopherson
2025-08-26 7:52 ` Michael S. Tsirkin
2025-08-26 14:03 ` Sean Christopherson [this message]
2025-08-26 14:15 ` Sebastian Andrzej Siewior
2025-08-26 14:40 ` Michael S. Tsirkin
2025-08-26 14:43 ` Michael S. Tsirkin
2025-08-26 0:40 ` [PATCH 2/3] vhost_task: Allow caller to omit handle_sigkill() callback Sean Christopherson
2025-08-26 6:29 ` Sebastian Andrzej Siewior
2025-08-26 0:40 ` [PATCH 3/3] KVM: x86/mmu: Don't register a sigkill callback for NX hugepage recovery tasks Sean Christopherson
2025-08-28 2:19 ` [PATCH 0/3] vhost_task: KVM: Fix a race where KVM wakes an exited task Lei Yang
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=aK2-tQLL-WN7Mqpb@google.com \
--to=seanjc@google.com \
--cc=bigeasy@linutronix.de \
--cc=jasowang@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=virtualization@lists.linux.dev \
/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.