On Fri, May 22, 2015 at 11:18:57PM +0200, Jiri Kosina wrote: > On Fri, 22 May 2015, Josh Poimboeuf wrote: > > > Hm, alternatives do complicate things a bit. It *is* a false positive, > > but not necessarily because its part of an alternative instruction > > block. > > > > The above code would be patched into memmove(), which is a leaf function > > because it doesn't call any other functions. Leaf functions don't need > > frame pointer logic, so we can ignore them. > > > > If instead the above code were patched into a non-leaf function, we'd > > have to change it to restore the frame pointer before returning. > > Is this really only a problem of alternatives? How about > dynamically-enabled tracepoints? I think tracepoints are only in C code, right? stackvalidate only analyzes asm code, so it's not a concern for this patch set. And I think tracepoints rely on normal call instructions, so they shouldn't cause any problems with frame pointers as far as I can tell. -- 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
