Hi Michael,
The r2 value is stored to the livepatch stack prior to entering into
the livepatched code, so accessing it will gurantee the previous value
is restored.
Also, yes, this bug is caused by tooling that "scoops out" pre-compiled
code and places it into the livepatch handler (e.g. kpatch)
Restores caller's toc pointer to r2, on a sibling call this will
uncorrupt the caller's toc pointer and otherwise will be redundant
Signed-off-by: Ryan Sullivan
---
arch/powerpc/kernel/trace/ftrace_entry.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/ke
Restores caller's toc pointer to r2, on a sibling call this will
uncorrupt the caller's toc pointer and otherwise will be redundant
Signed-off-by: Ryan Sullivan
---
arch/powerpc/kernel/trace/ftrace_entry.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/ke
Hello Michael,
In the case of no sibling call within the livepatch then the store is
only "restoring" the r2 value that was already there as it is stored
and retrieved from the livepatch stack. The only time that the r2 value
is corrupted is in the case of a sibling call and thus this additi
alue to caller's stack, on a sibling call this
will uncorrupt the caller's stack and otherwise will be redundant.
Signed-off-by: Ryan Sullivan
---
arch/powerpc/kernel/trace/ftrace_entry.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/kernel/trace/ftrace_entry.
