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

Michael Ellerman mpe at ellerman.id.au
Thu Nov 9 21:55:38 AEDT 2017


Josh Poimboeuf <jpoimboe at redhat.com> writes:
> On Tue, Nov 07, 2017 at 12:31:05PM +0100, Torsten Duwe wrote:
>> On Tue, Nov 07, 2017 at 07:34:29PM +1100, Michael Ellerman wrote:
>> > > So, just brainstorming a bit, here are the possible solutions I can
>> > > think of:
>> > >
>> > > a) Create a special klp stub for such calls (as in Kamalesh's patch)
>> > >
>> > > b) Have kpatch-build rewrite the function to insert nops after calls to
>> > >    previously-local functions.  This would also involve adjusting the
>> > >    offsets of intra-function branches and relocations which come
>> > >    afterwards in the same section.  And also patching up the DWARF
>> > >    debuginfo, if we care about that (I think we do).  And also patching
>> > >    up the jump tables which GCC sometimes creates for switch statements.
>> > >    Yuck.  I'm pretty sure this is a horrible idea.
>> > 
>> > It's fairly horrible. It might be *less* horrible if you generated an
>> > assembly listing using the compiler, modified that, and then fed that
>> > through the assembler and linker.
>
> Ah, that would work a lot better.

This should be fairly doable, you just need to spot function calls to
local symbols, eg. "bl bar", and if there's no nop trailing you add one.
The hard part is probably futzing with Makefiles to insert the extra step.

...
>> This might also be doable with a gcc "plugin", which would not require changes
>> to the compiler itself.
>
> Hm, that's not a bad idea.
>
>> OTOH there's no such thing as a weak static function...
>
> Yeah.  Instead of weak, maybe just make them global (remove the
> "static")?

I don't think that will work. The compiler still knows that the callee
is local to the caller, even if the callee is global.

Making the callee weak mans the compiler can't be sure the call will go
there, and so has to do a global call.

> Anyway, thanks for the ideas.  I may try them out and see what sticks.

Great, thanks for looking into it.

cheers


More information about the Linuxppc-dev mailing list