On Thu, 8 Mar 2018 10:26:16 -0600 Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > This doesn't seem to address some of my previous concerns: You're right. That discussion quickly headed towards objtool and I forgot about this one paragraph with the remarks. > - Bailing on interrupt/exception frames That is a good question. My current code keeps unwinding as long as the trace looks sane. If the exception frame has a valid code pointer in the LR slot it will continue. Couldn't there be cases where this is desirable? Should this be configurable? Not that I have an idea how this situation could occur for a thread that is current or sleeping... Michael, Balbir: is that possible? Any Idea how to reliably detect an exception frame? My approach would be to look at the next return address and compare it to the usual suspects (i.e. collect all "b ret" addresses in the EXCEPTION_COMMON macro, for BookS). > - Function graph tracing return address conversion > > - kretprobes return address conversion You mean like in arch/x86/kernel/unwind_frame.c the call to ftrace_graph_ret_addr ? Forgive me my directness but I don't see why these should be handled in arch-dependent code, other than maybe a hook, if inevitable, that calls back into the graph tracer / kretprobes in order to get the proper address, or simply call the trace unreliable in case it finds such a return address. I understand that x86 has a hard time with its multiple unwinders, but there should be a simpler, generic solution for all other architectures. Torsten -- 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
