lkml.org 
[lkml]   [2015]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC kgr on klp 0/9] kGraft on the top of KLP
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


\
 
 \ /
  Last update: 2015-05-05 08:21    [W:0.051 / U:1.752 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site