On Tue, 5 May 2015, Josh Poimboeuf wrote: > > 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? > > Yes. As I postulated before [1], there are two obstacles to achieving > reliable frame pointer stack traces: 1) missing frame pointer logic and > 2) exceptions. If either 1 or 2 was involved in the creation of any of > the frames on the stack, some frame pointers might be missing, and one > or more frames could be skipped by the stack walker. > > The first obstacle can be overcome and enforced at compile time using > stackvalidate [1]. > > The second obstacle can be overcome at run time with a future RFC: > something like a save_stack_trace_tsk_validate() function which does > some validations while it walks the stack. It can return an error if it > detects an exception frame. > > (It can also do some sanity checks like ensuring that it walks all the > way to the bottom of the stack and that each frame has a valid ktext > address. I also would propose a CONFIG_DEBUG_VALIDATE_STACK option > which tries to validate the stack on every call to schedule.) > > Then we can have the hybrid consistency model rely on > save_stack_trace_tsk_validate(). If the stack is deemed unsafe, we can > fall back to retrying later, or to the kGraft mode of user mode barrier > patching. > > Eventually I want to try to make *all* stacks reliable, even those with > exception frames. That would involve compile and run time validations > of DWARF data, and ensuring that DWARF and frame pointers are consistent > with each other. But those are general improvements which aren't > prerequisites for the hybrid model. > > [1] http://lkml.kernel.org/r/cover.1430770553.git.jpoimboe@xxxxxxxxxx Yup, I understand what is the goal here (and don't get me wrong, I am of course all for making frame pointer based stack traces reliable). The question I had was -- your patchset is now very x86-centric. If we are going to proceed with the hybrid patching model, we'd need to be able to extend to other architectures as easily as possible. I currently haven't yet tried to explore how difficult would it be to extend your aproach to other archs. Have you? Thanks, -- Jiri Kosina SUSE Labs -- 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
