Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 8 Mar 2022 11:28:24 +0100
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
Message-ID: <YicvyEbFzZIAut+4@alley>
References: <20220301140840.29345-1-zhouchengming@bytedance.com>
 <alpine.LSU.2.21.2203021052470.5895@pobox.suse.cz>
 <fe2b9225-44c3-2041-f8a3-6f17f9d1be40@bytedance.com>
 <alpine.LSU.2.21.2203030847430.704@pobox.suse.cz>
 <1929669c-7674-035b-8cf1-5b5007ecccec@bytedance.com>
 <c1ab3333-7fea-d2d5-272d-850f4c7afb74@redhat.com>
 <306a5d51-25e5-b7ce-cbdd-ca7e2f3a3ad5@bytedance.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <306a5d51-25e5-b7ce-cbdd-ca7e2f3a3ad5@bytedance.com>
Precedence: bulk

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