Messages in this thread | | | Date | Tue, 5 May 2015 08:14:50 +0200 (CEST) | From | Jiri Kosina <> | Subject | Re: [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
| |