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

[Jiri Kosina <jkosina@suse.cz>]

On Mon, 4 May 2015, Josh Poimboeuf wrote:

> > - 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?

Fair enoungh, I agree that in case of the hybrid aproach you're proposing 
the immediate model is not necessary.

> > - 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.  

It depends on bringing some sanity to freezing / parking / signal handling 
for kthreads, which is an independent work in progress in parallel.

> How does the patching state ever reach completion?

kthread context always calls the old code and it doesn't block the 
finalization; that's basically a documented feature for now.

That surely is a limitation and something the patch author has to be aware 
of, but I wouldn't really consider it a show stopper for now, for the 
reason pointed out above; it'll eventually be made to work, it's not a 
substantial issue.

> 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").

Agreed ...  under the condition that it can be made really 100% reliable 
*and* we'd be reasonably sure that we will be able to realistically 
achieve the same goal on other architectures as well. Have you even 
started exploring that space, please?

Thanks,

-- 
Jiri Kosina
SUSE Labs