[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wj9fNzDy0dTJzKj3RiSp-puwNawxQ5+ULMvKKjMRV=eqw@mail.gmail.com>
Date: Sat, 25 Jan 2025 10:31:49 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Paolo Bonzini <pbonzini@...hat.com>, "Michael S. Tsirkin" <mst@...hat.com>,
Christian Brauner <brauner@...nel.org>, "Eric W. Biederman" <ebiederm@...ssion.com>,
Oleg Nesterov <oleg@...hat.com>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [GIT PULL] KVM changes for Linux 6.14
On Sat, 25 Jan 2025 at 10:12, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Arguably the user space oddity is just strange and Paolo even calls it
> a bug, but at the same time, I do think user space can and should
> reasonably expect that it only has children that it created
> explicitly [..]
Note that I think that doing things like "io_uring" and getting IO
helper threads that way would very much count as "explicit children",
so I don't argue that all kernel helper threads would fall under this
category.
And I suspect that the normal vhost workers fall under that same kind
of "it's like io_uring". If you use VHOST_NEW_WORKER to create a
worker thread, then that's a pretty explicit "I have a child process".
So it's really just that hugepage recovery thread that seems to be a
bit "too" much of an implicit kernel helper thread that user space
kind of gets accidentally and implicitly just because of a kernel
implementation detail.
I'm sure the kvm hack to just start it later (at KVM_RUN time?) is
sufficient in practice, but it still feels conceptually iffy to me.
Linus
Powered by blists - more mailing lists