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 -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
