On Fri, Mar 01, 2019 at 04:12:01AM +0100, Jann Horn wrote: > When the ORC unwinder is invoked for an oops caused by IP==0, > it currently has no idea what to do because there is no debug information > for the stack frame of NULL. > > But if RIP is NULL, it is very likely that the last successfully executed > instruction was an indirect CALL/JMP, and it is possible to unwind out in > the same way as for the first instruction of a normal function. Hardcode > a corresponding ORC entry. > > > With an artificially-added NULL call in prctl_set_seccomp(), before this > patch, the trace is: > > Call Trace: > ? __x64_sys_prctl+0x402/0x680 > ? __ia32_sys_prctl+0x6e0/0x6e0 > ? __do_page_fault+0x457/0x620 > ? do_syscall_64+0x6d/0x160 > ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > After this patch, the trace looks like this: > > Call Trace: > __x64_sys_prctl+0x402/0x680 > ? __ia32_sys_prctl+0x6e0/0x6e0 > ? __do_page_fault+0x457/0x620 > do_syscall_64+0x6d/0x160 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > prctl_set_seccomp() still doesn't show up in the trace because for some > reason, tail call optimization is only disabled in builds that use the > frame pointer unwinder. > > Signed-off-by: Jann Horn <jannh@xxxxxxxxxx> Thanks for the patches! Acked-by: Josh Poimboeuf <jpoimboe@xxxxxxxxxx> > Is there a reason why the top-level Makefile only sets > -fno-optimize-sibling-calls if CONFIG_FRAME_POINTER is set? > I suspect that this is just a historical thing, because reliable > unwinding didn't work without frame pointers until ORC came along. > I'm not quite sure how best to express "don't do tail optimization if > either frame pointers are used or ORC is used" in a Makefile, and > whether we want an indirection through Kconfig for that, so I'm not > doing anything about it in this series. > Can someone send a patch to deal with it properly? Why would sibling calls be a problem for ORC? Once a function does a sibling call, it has effectively returned and shouldn't show up on the stack trace anyway. -- Josh
