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

Kamalesh Babulal kamalesh at linux.vnet.ibm.com
Mon Nov 13 22:38:02 AEDT 2017


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().

-- 
cheers,
Kamalesh.



More information about the Linuxppc-dev mailing list