From: Keith Busch <kbusch@kernel.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
michael.christie@oracle.com, Tejun Heo <tj@kernel.org>,
Luca Boccassi <bluca@debian.org>
Subject: Re: [PATCH] KVM: x86: switch hugepage recovery thread to vhost_task
Date: Thu, 19 Dec 2024 10:32:57 -0700 [thread overview]
Message-ID: <Z2RYyagu3phDFIac@kbusch-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <20241108130737.126567-1-pbonzini@redhat.com>
On Fri, Nov 08, 2024 at 08:07:37AM -0500, Paolo Bonzini wrote:
> Since the worker kthread is tied to a user process, it's better if
> it behaves similarly to user tasks as much as possible, including
> being able to send SIGSTOP and SIGCONT. In fact, vhost_task is all
> that kvm_vm_create_worker_thread() wanted to be and more: not only it
> inherits the userspace process's cgroups, it has other niceties like
> being parented properly in the process tree. Use it instead of the
> homegrown alternative.
This appears to be causing a user space regression. The library
"minijail" is used by virtual machine manager "crossvm". crossvm uses
minijail to fork processes, but the library requires the process be
single threaded. Prior to this patch, the process was single threaded,
but this change creates a relationship from the kvm thread to the user
process that fails minijail's test.
For reference, here's the affected library function reporting this
behavior change:
https://github.com/google/minijail/blob/main/rust/minijail/src/lib.rs#L987
Reverting the patch makes it work again.
Fwiw, I think the single threaded check may be misguided, but just doing
my due diligence to report the user space interaction.
next prev parent reply other threads:[~2024-12-19 17:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-08 13:07 [PATCH] KVM: x86: switch hugepage recovery thread to vhost_task Paolo Bonzini
2024-11-08 16:53 ` Tejun Heo
2024-11-09 0:23 ` Luca Boccassi
2024-11-13 23:56 ` Sean Christopherson
2024-11-14 12:02 ` Paolo Bonzini
2024-11-14 15:38 ` Sean Christopherson
2024-11-15 16:59 ` Michal Koutný
2024-11-18 12:42 ` Paolo Bonzini
2024-11-25 9:01 ` Michal Koutný
2024-11-25 11:22 ` Paolo Bonzini
2024-12-19 17:32 ` Keith Busch [this message]
2024-12-19 17:42 ` Paolo Bonzini
2024-12-19 18:08 ` Keith Busch
2024-12-19 20:30 ` Paolo Bonzini
2024-12-19 22:23 ` Keith Busch
2024-12-19 22:57 ` Paolo Bonzini
2024-12-19 23:31 ` Keith Busch
2025-01-13 15:35 ` Keith Busch
2025-01-14 18:10 ` Paolo Bonzini
2025-01-15 3:06 ` Sean Christopherson
2025-01-15 16:51 ` Keith Busch
2025-01-15 17:10 ` Paolo Bonzini
2025-01-15 19:03 ` Keith Busch
2025-01-22 11:38 ` Alyssa Ross
2025-01-22 14:56 ` Keith Busch
2025-01-22 22:32 ` Alyssa Ross
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=Z2RYyagu3phDFIac@kbusch-mbp.dhcp.thefacebook.com \
--to=kbusch@kernel.org \
--cc=bluca@debian.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.christie@oracle.com \
--cc=pbonzini@redhat.com \
--cc=tj@kernel.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