On Fri, Nov 10, 2017 at 2:28 PM, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > On Fri, Nov 10, 2017 at 01:06:25PM +1100, Balbir Singh wrote: >> On Fri, Nov 10, 2017 at 2:19 AM, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: >> > FWIW, I think it won't matter anyway. I'm currently pursuing the option >> > of inserting nops after local calls, because it has less runtime >> > complexity than using a stub. >> > >> > I think I've figured out a way to do it with a GCC plugin, but if that >> > doesn't work I'll try the asm listing sed approach suggested by Michael. >> > >> >> A plugin that runs for the new kernel with the patch? Just for >> specific files involved in the patch? > > The plugin will affect the code generation of all functions in the patch > module. So all calls in all replacement functions will have the nops. > > Here's a prototype (not yet fully tested): > > https://github.com/jpoimboe/kpatch/blob/TODO-ppc-fix/kpatch-build/gcc-plugins/ppc64le-plugin.c > Thanks! I looked at it briefly, I need to catch up with gcc plugins, code < 1000 was interesting. I guess now we don't need to pass via the new kpatch helper stub, we would just replace the no-ops and be done! I'd have to look closer, but I wonder what happens if a function has no global entry point (See http://mpe.github.io/posts/2016/05/23/kernel-live-patching-for-ppc64le/) section Understanding the TOC & entry points and the example of int_to_scsilun() Balbir Singh. -- 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
