From: Petr Mladek <pmladek@suse.com>
To: Seth Forshee <sforshee@digitalocean.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Andy Lutomirski <luto@kernel.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Jiri Kosina <jikos@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
Paolo Bonzini <pbonzini@redhat.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Jens Axboe <axboe@kernel.dk>,
Sean Christopherson <seanjc@google.com>,
linux-kernel@vger.kernel.org, live-patching@vger.kernel.org,
kvm@vger.kernel.org
Subject: Re: [PATCH v2] entry/kvm: Make vCPU tasks exit to userspace when a livepatch is pending
Date: Wed, 4 May 2022 16:57:32 +0200 [thread overview]
Message-ID: <20220504145732.GD8069@pathway.suse.cz> (raw)
In-Reply-To: <YnKRN1zXKuh/gIMl@do-x1extreme>
On Wed 2022-05-04 09:44:07, Seth Forshee wrote:
> On Wed, May 04, 2022 at 04:28:09PM +0200, Petr Mladek wrote:
> > On Wed 2022-05-04 08:50:22, Seth Forshee wrote:
> > > On Wed, May 04, 2022 at 03:07:53PM +0200, Petr Mladek wrote:
> > > > On Tue 2022-05-03 12:49:34, Seth Forshee wrote:
> > > > > A task can be livepatched only when it is sleeping or it exits to
> > > > > userspace. This may happen infrequently for a heavily loaded vCPU task,
> > > > > leading to livepatch transition failures.
> > > >
> > > > The problem was solved by sending a fake signal, see the commit
> > > > 0b3d52790e1cfd6b80b826 ("livepatch: Remove signal sysfs attribute").
> > > > It was achieved by calling signal_wake_up(). It set TIF_SIGPENDING
> > > > and woke the task. It interrupted the syscall and the task was
> > > > transitioned when leaving to the userspace.
> > > >
> > > > signal_wake_up() was later replaced by set_notify_signal(),
> > > > see the commit 8df1947c71ee53c7e21 ("livepatch: Replace
> > > > the fake signal sending with TIF_NOTIFY_SIGNAL infrastructure").
> > > > The difference is that set_notify_signal() uses TIF_NOTIFY_SIGNAL
> > > > instead of TIF_SIGPENDING.
> > > >
> > > > The effect is the same when running on a real hardware. The syscall
> > > > gets interrupted and exit_to_user_mode_loop() is called where
> > > > the livepatch state is updated (task migrated).
> > > >
> > > > But it works a different way in kvm where the task works are
> > > > called in the guest mode and the task does not return into
> > > > the user space in the host mode.
> > >
> > > > > --- a/kernel/entry/kvm.c
> > > > > +++ b/kernel/entry/kvm.c
> > > > > @@ -14,7 +14,12 @@ static int xfer_to_guest_mode_work(struct kvm_vcpu *vcpu, unsigned long ti_work)
> > > > > task_work_run();
> > > > > }
> > > > >
> > > > > - if (ti_work & _TIF_SIGPENDING) {
> > > > > + /*
> > > > > + * When a livepatch is pending, force an exit to userspace
> > > > > + * as though a signal is pending to allow the task to be
> > > > > + * patched.
> > > > > + */
> > > > > + if (ti_work & (_TIF_SIGPENDING | _TIF_PATCH_PENDING)) {
> > > > > kvm_handle_signal_exit(vcpu);
> >
> > Another problem. Is it safe to call kvm_handle_signal_exit(vcpu)
> > for kthreads?
> >
> > kthreads have _TIF_PATCH_PENDING when they need the livepatch transition.
> > But kthreads never leave kernel so we do not send the fake signal
> > signals to them.
>
> xfer_to_guest_mode_handle_work() should only be getting called on user
> threads running ioctl(KVM_RUN).
Great!
> > In this case, we should revert the commit 8df1947c71ee53c7e21
> > ("livepatch: Replace the fake signal sending with TIF_NOTIFY_SIGNAL
> > infrastructure"). The flag TIF_NOTIFY_SIGNAL clearly does not guarantee
> > restarting the syscall or exiting to the user space with -EINTR.
> >
> > It should solve this problem. And it looks like a cleaner solution
> > to me.
>
> It looks like that should fix the issue. I'll test to confirm.
Even better solution would be what Eric suggested, see
https://lore.kernel.org/r/87r159fkmp.fsf@email.froward.int.ebiederm.org
But we need to make sure that the syscall really gets restarted
when the livepatch state is updated.
Best Regards,
Petr
next prev parent reply other threads:[~2022-05-04 14:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-03 17:49 [PATCH v2] entry/kvm: Make vCPU tasks exit to userspace when a livepatch is pending Seth Forshee
2022-05-03 17:53 ` Seth Forshee
2022-05-04 1:08 ` kernel test robot
2022-05-04 12:44 ` Thomas Gleixner
2022-05-04 13:07 ` Petr Mladek
2022-05-04 13:50 ` Seth Forshee
2022-05-04 14:28 ` Petr Mladek
2022-05-04 14:44 ` Seth Forshee
2022-05-04 14:57 ` Petr Mladek [this message]
2022-05-04 14:53 ` Eric W. Biederman
2022-05-04 14:16 ` Eric W. Biederman
2022-05-04 15:12 ` Petr Mladek
2022-05-04 17:37 ` Seth Forshee
2022-05-04 15:01 ` kernel test robot
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=20220504145732.GD8069@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=axboe@kernel.dk \
--cc=ebiederm@xmission.com \
--cc=jikos@kernel.org \
--cc=jpoimboe@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mbenes@suse.cz \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=seanjc@google.com \
--cc=sforshee@digitalocean.com \
--cc=tglx@linutronix.de \
/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