From: Petr Mladek <pmladek@suse.com>
To: Chengming Zhou <zhouchengming@bytedance.com>
Cc: Joe Lawrence <joe.lawrence@redhat.com>,
Miroslav Benes <mbenes@suse.cz>,
jpoimboe@redhat.com, jikos@kernel.org,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
songmuchun@bytedance.com, qirui.001@bytedance.com
Subject: Re: [External] Re: [PATCH] livepatch: Only block the removal of KLP_UNPATCHED forced transition patch
Date: Tue, 8 Mar 2022 11:28:24 +0100 [thread overview]
Message-ID: <YicvyEbFzZIAut+4@alley> (raw)
In-Reply-To: <306a5d51-25e5-b7ce-cbdd-ca7e2f3a3ad5@bytedance.com>
On Fri 2022-03-04 23:14:15, Chengming Zhou wrote:
> On 2022/3/3 11:43 下午, Joe Lawrence wrote:
> > On 3/3/22 5:33 AM, Chengming Zhou wrote:
> >> On 2022/3/3 3:51 下午, Miroslav Benes wrote:
> >> Apart from this reason, another reason we may use "force" transition
> >> is that we want to speed up the transition process of some patches
> >> when load them, and we can make sure these patches are safe to do so.
> >> (just like a consistency model check disable option when load a patch)
> >>
> > Interesting use case. Can you share any example livepatches where the
> > transition time was exceptionally long and that lead to requiring this
> > patch?
>
> Sorry, I haven't easy reproducible testcase on hand, maybe I could try to
> make one to simulate the production environment later.
An artificial test case is not much useful. We would like to know if you
met the problem in the real life. It would be great to know more
details if it really happened.
> > From a kpatch developer's perspective, it would be interesting to read
> > how you go about ensuring forced livepatch safety. We don't generally
> > build forced livepatches, so I'm curious how the dev/review process goes.
>
> We also use kpatch-build for some patches too, but for some other patches,
> which need to add new members to some struct type, or fix some kernel function
> bugs, we may need to rewrite the source patch to make a livepatch module.
>
> There are some types that don't need per-task consistency or even can replace
> the old functions when tasks stack in the old functions. We may want to use
> "force" transition in case load process timeout.
What is the motivation for the timeout, please?
The "force" functionality was introduced as a last resort solution.
It might be useful when the transition gets blocked and another
transition is needed.
"force" should be used carefully. Users should be sure that it is
really safe in the current state.
Note that forced transition does not magically makes the system
patched. If a process is sleeping on a non-patched function then
it will continue running the old code until it returns
the non-patched function.
Best Regards,
Petr
prev parent reply other threads:[~2022-03-08 10:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-01 14:08 [PATCH] livepatch: Only block the removal of KLP_UNPATCHED forced transition patch Chengming Zhou
2022-03-02 9:55 ` Miroslav Benes
2022-03-03 6:51 ` [External] " Chengming Zhou
2022-03-03 7:51 ` Miroslav Benes
2022-03-03 10:33 ` Chengming Zhou
2022-03-03 15:43 ` Joe Lawrence
2022-03-04 15:14 ` Chengming Zhou
2022-03-08 10:28 ` Petr Mladek [this message]
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=YicvyEbFzZIAut+4@alley \
--to=pmladek@suse.com \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=qirui.001@bytedance.com \
--cc=songmuchun@bytedance.com \
--cc=zhouchengming@bytedance.com \
/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