On Fri, Nov 10, 2017 at 2:19 AM, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > 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. > A plugin that runs for the new kernel with the patch? Just for specific files involved in the patch? 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
