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

Michael Ellerman mpe at ellerman.id.au
Wed Nov 15 21:19:34 AEDT 2017


Kamalesh Babulal <kamalesh at linux.vnet.ibm.com> writes:

> On Monday 13 November 2017 02:08 PM, Balbir Singh wrote:
>> On Fri, Nov 10, 2017 at 2:28 PM, Josh Poimboeuf <jpoimboe at redhat.com> 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 at redhat.com> 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
>>>
>>
>
> [...]
>
>> 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()
>>
>
> int_to_scsilun() is accessed via global entry point, but the TOC setup
> part in the function prologue is skipped as the function doesn't have a
> need to save/restore TOC. The reason begin, it doesn't calls any global
> functions, thus the r2 register is not clobbered.
>
> As per my understanding, the plug-in inserts a nop instruction after
> branch to a function called via localentry a.k.a call to local
> function. In case of int_to_scsilun(), the plug-in will not modify the
> function in any way, as there are no local calls also made by the
> int_to_scsilun().

Yeah there should be no issue. This happens all the time, ie. the
compiler sees it needs to make a global call, inserts the nop, but
then it turns out the callee didn't need to use the TOC anyway.

cheers


More information about the Linuxppc-dev mailing list