Re: [RFC PATCH 2/2] livepatch: Implement livepatch hybrid mode

[Josh Poimboeuf <jpoimboe@kernel.org>]

On Fri, Feb 07, 2025 at 11:16:45AM +0800, Yafang Shao wrote:
> On Fri, Feb 7, 2025 at 10:31 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> > Why does this happen?
> 
> It occurs during the KLP transition. It seems like the KLP transition
> is taking too long.
> 
> [20329703.332453] livepatch: enabling patch 'livepatch_61_release6'
> [20329703.340417] livepatch: 'livepatch_61_release6': starting
> patching transition
> [20329715.314215] rcu_tasks_wait_gp: rcu_tasks grace period 1109765 is
> 10166 jiffies old.
> [20329737.126207] rcu_tasks_wait_gp: rcu_tasks grace period 1109769 is
> 10219 jiffies old.
> [20329752.018236] rcu_tasks_wait_gp: rcu_tasks grace period 1109773 is
> 10199 jiffies old.
> [20329754.848036] livepatch: 'livepatch_61_release6': patching complete

How specifically does the KLP transition trigger rcu_tasks workings?

> Before the new atomic replace patch is added to the func_stack list,
> the old patch is already set to nop. If klp_ftrace_handler() is
> triggered at this point, it will effectively do nothing—in other
> words, it will execute the original function.
> I might be wrong.

That's not actually how it works.  klp_add_nops() probably needs some
better comments.

It adds nops to the *new* patch so that all the functions in the old
patch(es) get replaced, even those which don't have a corresponding
function in the new patch.

The justification for your patch seems to be "here are some bugs, this
patch helps work around them", which isn't very convincing.  Instead we
need to understand the original bugs and fix them.

-- 
Josh