On Monday 13 November 2017 02:08 PM, Balbir Singh wrote:
On Fri, Nov 10, 2017 at 2:28 PM, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> 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@xxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe live-patching" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
