Re: [RFC kgr on klp 0/9] kGraft on the top of KLP

[Josh Poimboeuf <jpoimboe@redhat.com>]

On Tue, May 05, 2015 at 12:48:22AM +0200, Jiri Kosina wrote:
> On Mon, 4 May 2015, Josh Poimboeuf wrote:
> > Why do we need multiple consistency models?
> 
> Well, I am pretty sure we need always at least two:
> 
> - the "immediate" one, where the code redirection flip is switched 
>   unconditionally and immediately (i.e. exactly what we currently have in 
>   Linus' tree); semantically applicable to many patches, but not all of 
>   them
> 
> - something that fills the "but not all of them" gap above.

What's the benefit of having the "immediate" model in addition to
the more comprehensive model?

> Both of the solutions that have been presnted so far have some drawbacks 
> that need to be discussed further. To me, the "highlights" (in the 
> "drawbacks" space) are:
> 
> - any method that is stack-checking-based basically means that we have to
>   functionally 100% rely on stack unwinding correctness. We have never 
>   done that before, and current stack unwinder is not ready for that 
>   (Josh is working on improving that);

I wouldn't call it a drawback.  More like a deal breaker :-) But yeah,
I'm working on that.

>   plus it can cause the patching to fail under certain circumstances

Assuming you're talking about the kGraft/kpatch hybrid RFC, it actually
doesn't fail.  It falls back to asynchronous lazy migration for any
straggler tasks.

> - the kGraft method is not (yet) able to patch kernel threads, and allows 
>   for multiple instances of the patched functions to be running in 
>   parallel (i.e. patch author needs to be aware of this constaint, and 
>   write the code accordingly)

Not being able to patch kthreads sounds like a huge drawback, if not a
deal breaker.  How does the patching state ever reach completion?

> This is exactly why we are submitting the kGraft-on-klp patchset, so that 
> we have concurrent implementations (sharing the same goal) to compare, and 
> ultimately merge whatever the best possible outcome will be.

Another big downside to kGraft, assuming you want the patching to
complete within a realistic period of time, is that you have to wake up
all the sleeping tasks and send them through their signal handling
paths.  I would say it's orders of magnitude more disruptive and much
riskier compared to walking the stacks (again, assuming we can make
stack walking "safe").

-- 
Josh