Re: [PATCH v3] kernel/module_64.c: Add REL24 relocation support of livepatch symbols

[Josh Poimboeuf <jpoimboe@redhat.com>]

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