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

Balbir Singh bsingharora at gmail.com
Fri Nov 10 13:06:25 AEDT 2017


On Fri, Nov 10, 2017 at 2:19 AM, Josh Poimboeuf <jpoimboe at redhat.com> 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.


More information about the Linuxppc-dev mailing list