From: Seth Forshee <sforshee@kernel.org>
To: Petr Mladek <pmladek@suse.com>
Cc: Jason Wang <jasowang@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Jiri Kosina <jikos@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
Joe Lawrence <joe.lawrence@redhat.com>,
Josh Poimboeuf <jpoimboe@kernel.org>,
virtualization@lists.linux-foundation.org, kvm@vger.kernel.org,
netdev@vger.kernel.org, live-patching@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] vhost: check for pending livepatches from vhost worker kthreads
Date: Tue, 24 Jan 2023 11:21:39 -0600 [thread overview]
Message-ID: <Y9ATo5FukOhphwqT@do-x1extreme> (raw)
In-Reply-To: <Y8/ohzRGcOiqsh69@alley>
On Tue, Jan 24, 2023 at 03:17:43PM +0100, Petr Mladek wrote:
> On Fri 2023-01-20 16:12:22, Seth Forshee (DigitalOcean) wrote:
> > Livepatch relies on stack checking of sleeping tasks to switch kthreads,
> > so a busy kthread can block a livepatch transition indefinitely. We've
> > seen this happen fairly often with busy vhost kthreads.
>
> To be precise, it would be "indefinitely" only when the kthread never
> sleeps.
>
> But yes. I believe that the problem is real. It might be almost
> impossible to livepatch some busy kthreads, especially when they
> have a dedicated CPU.
>
>
> > Add a check to call klp_switch_current() from vhost_worker() when a
> > livepatch is pending. In testing this allowed vhost kthreads to switch
> > immediately when they had previously blocked livepatch transitions for
> > long periods of time.
> >
> > Signed-off-by: Seth Forshee (DigitalOcean) <sforshee@kernel.org>
> > ---
> > drivers/vhost/vhost.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > index cbe72bfd2f1f..d8624f1f2d64 100644
> > --- a/drivers/vhost/vhost.c
> > +++ b/drivers/vhost/vhost.c
> > @@ -366,6 +367,9 @@ static int vhost_worker(void *data)
> > if (need_resched())
> > schedule();
> > }
> > +
> > + if (unlikely(klp_patch_pending(current)))
> > + klp_switch_current();
>
> I suggest to use the following intead:
>
> if (unlikely(klp_patch_pending(current)))
> klp_update_patch_state(current);
>
> We already use this in do_idle(). The reason is basically the same.
> It is almost impossible to livepatch the idle task when a CPU is
> very idle.
>
> klp_update_patch_state(current) does not check the stack.
> It switches the task immediately.
>
> It should be safe because the kthread never leaves vhost_worker().
> It means that the same kthread could never re-enter this function
> and use the new code.
My knowledge of livepatching internals is fairly limited, so I'll accept
it if you say that it's safe to do it this way. But let me ask about one
scenario.
Let's say that a livepatch is loaded which replaces vhost_worker(). New
vhost worker threads are started which use the replacement function. Now
if the patch is disabled, these new worker threads would be switched
despite still running the code from the patch module, correct? Could the
module then be unloaded, freeing the memory containing the code these
kthreads are executing?
Thanks,
Seth
next prev parent reply other threads:[~2023-01-24 17:21 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-20 22:12 [PATCH 0/2] vhost: improve livepatch switching for heavily loaded vhost worker kthreads Seth Forshee (DigitalOcean)
2023-01-20 22:12 ` [PATCH 1/2] livepatch: add an interface for safely switching kthreads Seth Forshee (DigitalOcean)
2023-01-20 22:12 ` [PATCH 2/2] vhost: check for pending livepatches from vhost worker kthreads Seth Forshee (DigitalOcean)
2023-01-24 14:17 ` Petr Mladek
2023-01-24 17:21 ` Seth Forshee [this message]
2023-01-25 11:34 ` Petr Mladek
2023-01-25 16:57 ` Seth Forshee
2023-01-26 11:16 ` Petr Mladek
2023-01-26 11:49 ` Petr Mladek
2023-01-22 8:34 ` [PATCH 0/2] vhost: improve livepatch switching for heavily loaded " Michael S. Tsirkin
2023-01-26 17:03 ` Petr Mladek
2023-01-26 21:12 ` Seth Forshee (DigitalOcean)
2023-01-27 4:43 ` Josh Poimboeuf
2023-01-27 10:37 ` Peter Zijlstra
2023-01-27 12:09 ` Petr Mladek
2023-01-27 14:37 ` Seth Forshee
2023-01-27 16:52 ` Josh Poimboeuf
2023-01-27 17:09 ` Josh Poimboeuf
2023-01-27 22:11 ` Josh Poimboeuf
2023-01-30 12:40 ` Peter Zijlstra
2023-01-30 17:50 ` Seth Forshee
2023-01-30 18:18 ` Josh Poimboeuf
2023-01-30 18:36 ` Mark Rutland
2023-01-30 19:48 ` Josh Poimboeuf
2023-01-31 1:53 ` Song Liu
2023-01-31 10:22 ` Mark Rutland
2023-01-31 16:38 ` Josh Poimboeuf
2023-02-01 11:10 ` Mark Rutland
2023-02-01 16:57 ` Josh Poimboeuf
2023-02-01 17:11 ` Mark Rutland
2023-01-30 19:59 ` Josh Poimboeuf
2023-01-31 10:02 ` Peter Zijlstra
2023-01-27 20:02 ` Seth Forshee
2023-01-27 11:19 ` Petr Mladek
2023-01-27 14:57 ` Seth Forshee
2023-01-30 9:55 ` Petr Mladek
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=Y9ATo5FukOhphwqT@do-x1extreme \
--to=sforshee@kernel.org \
--cc=jasowang@redhat.com \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pmladek@suse.com \
--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).