]> asedeno.scripts.mit.edu Git - linux.git/commitdiff
powerpc/vdso: Correct call frame information
authorAlan Modra <amodra@gmail.com>
Fri, 14 Sep 2018 03:40:04 +0000 (13:10 +0930)
committerPaul Mackerras <paulus@ozlabs.org>
Fri, 14 Sep 2018 03:47:31 +0000 (13:47 +1000)
Call Frame Information is used by gdb for back-traces and inserting
breakpoints on function return for the "finish" command.  This failed
when inside __kernel_clock_gettime.  More concerning than difficulty
debugging is that CFI is also used by stack frame unwinding code to
implement exceptions.  If you have an app that needs to handle
asynchronous exceptions for some reason, and you are unlucky enough to
get one inside the VDSO time functions, your app will crash.

What's wrong:  There is control flow in __kernel_clock_gettime that
reaches label 99 without saving lr in r12.  CFI info however is
interpreted by the unwinder without reference to control flow: It's a
simple matter of "Execute all the CFI opcodes up to the current
address".  That means the unwinder thinks r12 contains the return
address at label 99.  Disabuse it of that notion by resetting CFI for
the return address at label 99.

Note that the ".cfi_restore lr" could have gone anywhere from the
"mtlr r12" a few instructions earlier to the instruction at label 99.
I put the CFI as late as possible, because in general that's best
practice (and if possible grouped with other CFI in order to reduce
the number of CFI opcodes executed when unwinding).  Using r12 as the
return address is perfectly fine after the "mtlr r12" since r12 on
that code path still contains the return address.

__get_datapage also has a CFI error.  That function temporarily saves
lr in r0, and reflects that fact with ".cfi_register lr,r0".  A later
use of r0 means the CFI at that point isn't correct, as r0 no longer
contains the return address.  Fix that too.

Signed-off-by: Alan Modra <amodra@gmail.com>
Tested-by: Reza Arbab <arbab@linux.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
arch/powerpc/kernel/vdso32/datapage.S
arch/powerpc/kernel/vdso32/gettimeofday.S
arch/powerpc/kernel/vdso64/datapage.S
arch/powerpc/kernel/vdso64/gettimeofday.S

index 3745113fcc652d8ca3e66692aaab7d87f7ea9338..2a7eb5452aba79fc4d2b2c709642b0e71cfc6130 100644 (file)
@@ -37,6 +37,7 @@ data_page_branch:
        mtlr    r0
        addi    r3, r3, __kernel_datapage_offset-data_page_branch
        lwz     r0,0(r3)
+  .cfi_restore lr
        add     r3,r0,r3
        blr
   .cfi_endproc
index 769c2624e0a6b4dc162d12781d29198a84d51786..1e0bc5955a400601b106949f14c7a0ca64d1a6a6 100644 (file)
@@ -139,6 +139,7 @@ V_FUNCTION_BEGIN(__kernel_clock_gettime)
         */
 99:
        li      r0,__NR_clock_gettime
+  .cfi_restore lr
        sc
        blr
   .cfi_endproc
index abf17feffe4048af18382a075b01553f7e9be00e..bf966869151169b6b101675b4822609375058019 100644 (file)
@@ -37,6 +37,7 @@ data_page_branch:
        mtlr    r0
        addi    r3, r3, __kernel_datapage_offset-data_page_branch
        lwz     r0,0(r3)
+  .cfi_restore lr
        add     r3,r0,r3
        blr
   .cfi_endproc
index c002adcc694c66966c67fceba4db34a1bf685059..a4ed9edfd5f0b694288478683858f0ed3f306516 100644 (file)
@@ -169,6 +169,7 @@ V_FUNCTION_BEGIN(__kernel_clock_gettime)
         */
 99:
        li      r0,__NR_clock_gettime
+  .cfi_restore lr
        sc
        blr
   .cfi_endproc