On Thu, Nov 09, 2017 at 04:49:05PM +0530, Naveen N. Rao wrote: > > > > > d) Have kpatch-build do some other kind of transformation? For example, > > > > > maybe it could generate klp stubs which the callee calls into. Each > > > > > klp stub could then do a proper global call to the SHN_LIVEPATCH > > > > > symbol. > > > > > That could work. > > > Indeed. There is no reason to load that off onto the kernel module loader. > > > > I agree that doing the same work in tooling would be better than adding > > complexity to the kernel. > > [In case we're considering this as an option...] > > While I agree that it's better to do this in the tool in general, for this > particular scenario, I think it is better to do this in the kernel. > > From what I understand, the challenge here is the need to save/restore toc, > *without* creating a local stack frame for the stub to use. So, we will have > to use the livepatch stack in one form or the other. I'm not sure if we can > do anything else in a klp stub. > > And, if we have to use the livepatch stack, I think it is better to let the > kernel control that so that kpatch doesn't need to change for any changes in > livepatch_handler() for instance. The current patch reuses > livepatch_handler() and makes its usage for kpatch quite explicit. 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. -- 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
