* WARNING: kernel stack frame pointer has bad value @ 2017-04-19 3:37 Steven Rostedt 2017-04-19 13:44 ` Josh Poimboeuf 0 siblings, 1 reply; 6+ messages in thread From: Steven Rostedt @ 2017-04-19 3:37 UTC (permalink / raw) To: Josh Poimboeuf Cc: LKML, Ingo Molnar, Thomas Gleixner, Andy Lutomirski, H. Peter Anvin [-- Attachment #1: Type: text/plain, Size: 5620 bytes --] Josh, I'm starting to get a bunch of these warnings, and I'm thinking they are false positives. The stack frame error is recorded at a call from entry_SYSCALL_64_fastpath, where I would expect the bp to not be valid. To trigger this, I only need to go into /sys/kernel/debug/tracing and echo function > current_tracer then cat trace. Maybe function tracer stack frames is messing it up some how, but it always fails at the entry call. Here's the dump; WARNING: kernel stack frame pointer at ffff8800bda0ff30 in sshd:1090 has bad value 000055b32abf1fa8 unwind stack type:0 next_sp: (null) mask:6 graph_idx:0 ffff8800bda0fd28: ffffffff81cf502a (entry_SYSCALL_64_fastpath+0x18/0xad) ffff8800bda0fd30: ffffffff810dc940 (sigprocmask+0x150/0x150) ffff8800bda0fd38: ffffffff81cf502a (entry_SYSCALL_64_fastpath+0x18/0xad) ffff8800bda0fd40: ffff8800c7e60040 (0xffff8800c7e60040) ffff8800bda0fd48: ffff8800bda0fe08 (0xffff8800bda0fe08) ffff8800bda0fd50: ffffffff825393c0 (ftrace_trace_arrays+0x40/0x40) ffff8800bda0fd58: ffff8800c7e60040 (0xffff8800c7e60040) ffff8800bda0fd60: 0000000000000008 (0x8) ffff8800bda0fd68: 00000000001a0800 (0x1a0800) ffff8800bda0fd70: 0000000000000000 ... ffff8800bda0fd78: fffffbfff04a727c (0xfffffbfff04a727c) ffff8800bda0fd80: ffffffff8122c8bb (trace_function+0x2b/0x120) ffff8800bda0fd88: dffffc0000000000 (0xdffffc0000000000) ffff8800bda0fd90: ffffffff810dc940 (sigprocmask+0x150/0x150) ffff8800bda0fd98: ffffffff825393e0 (global_trace+0x20/0x1680) ffff8800bda0fda0: ffffffffffffff7d (0xffffffffffffff7d) ffff8800bda0fda8: ffffffff8122c8bb (trace_function+0x2b/0x120) ffff8800bda0fdb0: 0000000000000010 (0x10) ffff8800bda0fdb8: 0000000000000246 (0x246) ffff8800bda0fdc0: ffff8800bda0fdd0 (0xffff8800bda0fdd0) ffff8800bda0fdc8: 0000000000000018 (0x18) ffff8800bda0fdd0: 00000000a02e0077 (0xa02e0077) ffff8800bda0fdd8: 0000000000000246 (0x246) ffff8800bda0fde0: ffff8800c7e60040 (0xffff8800c7e60040) ffff8800bda0fde8: ffff8800c7e60040 (0xffff8800c7e60040) ffff8800bda0fdf0: 0000000000000007 (0x7) ffff8800bda0fdf8: ffffffff810dc940 (sigprocmask+0x150/0x150) ffff8800bda0fe00: ffffffff81cf502a (entry_SYSCALL_64_fastpath+0x18/0xad) ffff8800bda0fe08: ffff8800bda0fe68 (0xffff8800bda0fe68) ffff8800bda0fe10: ffffffff81238168 (function_trace_call+0x208/0x260) ffff8800bda0fe18: 0000000000026f10 (0x26f10) ffff8800bda0fe20: ffff8800c7e621f0 (0xffff8800c7e621f0) ffff8800bda0fe28: 0000000000026f10 (0x26f10) ffff8800bda0fe30: ffff8800d3ea6f10 (0xffff8800d3ea6f10) ffff8800bda0fe38: 8000000000000010 (0x8000000000000010) ffff8800bda0fe40: 00007ffffd1f4e80 (0x7ffffd1f4e80) ffff8800bda0fe48: 00007ffffd1f4e00 (0x7ffffd1f4e00) ffff8800bda0fe50: 0000000000000000 ... ffff8800bda0fe58: 00007ffffd1f4f8f (0x7ffffd1f4f8f) ffff8800bda0fe60: 000055b32a9a2a51 (0x55b32a9a2a51) ffff8800bda0fe68: ffff8800bda0ff20 (0xffff8800bda0ff20) ffff8800bda0fe70: ffffffffa02e0077 (0xffffffffa02e0077) ffff8800bda0fe78: 000055b32bdc57c0 (0x55b32bdc57c0) ffff8800bda0fe80: 0000000041b58ab3 (0x41b58ab3) ffff8800bda0fe88: ffffffff8233e3f0 (ONEf+0x16e40/0x5840d) ffff8800bda0fe90: ffff8800bda0fed0 (0xffff8800bda0fed0) ffff8800bda0fe98: 000055b32abf1fa8 (0x55b32abf1fa8) ffff8800bda0fea0: ffff8800bda0fee0 (0xffff8800bda0fee0) ffff8800bda0fea8: ffff8800c7e60040 (0xffff8800c7e60040) ffff8800bda0feb0: ffffffff81cf5017 (entry_SYSCALL_64_fastpath+0x5/0xad) ffff8800bda0feb8: 00000000001a0800 (0x1a0800) ffff8800bda0fec0: 0000000000000000 ... ffff8800bda0fec8: 000000000000000e (0xe) ffff8800bda0fed0: 0000000000000008 (0x8) ffff8800bda0fed8: 00007ffffd1f4e00 (0x7ffffd1f4e00) ffff8800bda0fee0: 00007ffffd1f4e80 (0x7ffffd1f4e80) ffff8800bda0fee8: 0000000000000000 ... ffff8800bda0fef0: ffff8800bda0ff48 (0xffff8800bda0ff48) ffff8800bda0fef8: ffffffff810dc945 (SyS_rt_sigprocmask+0x5/0x1a0) ffff8800bda0ff00: ffff8800c7e60040 (0xffff8800c7e60040) ffff8800bda0ff08: 0000000000000008 (0x8) ffff8800bda0ff10: 00000000001a0800 (0x1a0800) ffff8800bda0ff18: 0000000000000000 ... ffff8800bda0ff20: ffff8800bda0ff30 (0xffff8800bda0ff30) ffff8800bda0ff28: ffffffff810dc945 (SyS_rt_sigprocmask+0x5/0x1a0) ffff8800bda0ff30: 000055b32abf1fa8 (0x55b32abf1fa8) ffff8800bda0ff38: ffffffff81cf502a (entry_SYSCALL_64_fastpath+0x18/0xad) ffff8800bda0ff40: 000055b32abf1fa8 (0x55b32abf1fa8) ffff8800bda0ff48: ffffffff810dc945 (SyS_rt_sigprocmask+0x5/0x1a0) ffff8800bda0ff50: ffffffff81cf502a (entry_SYSCALL_64_fastpath+0x18/0xad) ffff8800bda0ff58: 00000000258c9a9a (0x258c9a9a) ffff8800bda0ff60: 000000009a954c2d (0x9a954c2d) ffff8800bda0ff68: 00000000fc397de1 (0xfc397de1) ffff8800bda0ff70: 000000002badc874 (0x2badc874) ffff8800bda0ff78: ffff8800bda0ff98 (0xffff8800bda0ff98) ffff8800bda0ff80: ffffffff81149040 (trace_hardirqs_off_caller+0xc0/0x110) ffff8800bda0ff88: 0000000000000246 (0x246) ffff8800bda0ff90: 0000000000000008 (0x8) ffff8800bda0ff98: 00000000001a0800 (0x1a0800) ffff8800bda0ffa0: 0000000000000000 ... ffff8800bda0ffa8: ffffffffffffffda (0xffffffffffffffda) ffff8800bda0ffb0: 00007fb25d228c10 (0x7fb25d228c10) ffff8800bda0ffb8: 00007ffffd1f4e00 (0x7ffffd1f4e00) ffff8800bda0ffc0: 00007ffffd1f4e80 (0x7ffffd1f4e80) ffff8800bda0ffc8: 0000000000000000 ... ffff8800bda0ffd0: 000000000000000e (0xe) ffff8800bda0ffd8: 00007fb25d228c10 (0x7fb25d228c10) ffff8800bda0ffe0: 0000000000000033 (0x33) ffff8800bda0ffe8: 0000000000000246 (0x246) ffff8800bda0fff0: 00007ffffd1f4de8 (0x7ffffd1f4de8) ffff8800bda0fff8: 000000000000002b (0x2b) ------------[ cut here ]------------ I trigger this on 4.11-rc3 and I attached the config. -- Steve [-- Attachment #2: config.gz --] [-- Type: application/gzip, Size: 27549 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: WARNING: kernel stack frame pointer has bad value 2017-04-19 3:37 WARNING: kernel stack frame pointer has bad value Steven Rostedt @ 2017-04-19 13:44 ` Josh Poimboeuf 2017-04-19 14:12 ` Steven Rostedt 0 siblings, 1 reply; 6+ messages in thread From: Josh Poimboeuf @ 2017-04-19 13:44 UTC (permalink / raw) To: Steven Rostedt Cc: LKML, Ingo Molnar, Thomas Gleixner, Andy Lutomirski, H. Peter Anvin On Tue, Apr 18, 2017 at 11:37:14PM -0400, Steven Rostedt wrote: > Josh, > > I'm starting to get a bunch of these warnings, and I'm thinking they > are false positives. The stack frame error is recorded at a call from > entry_SYSCALL_64_fastpath, where I would expect the bp to not be valid. > > To trigger this, I only need to go into /sys/kernel/debug/tracing and > echo function > current_tracer then cat trace. Maybe function tracer > stack frames is messing it up some how, but it always fails at the > entry call. > > Here's the dump; > > WARNING: kernel stack frame pointer at ffff8800bda0ff30 in sshd:1090 has bad value 000055b32abf1fa8 ... > ffff8800bda0ff20: ffff8800bda0ff30 (0xffff8800bda0ff30) > ffff8800bda0ff28: ffffffff810dc945 (SyS_rt_sigprocmask+0x5/0x1a0) > ffff8800bda0ff30: 000055b32abf1fa8 (0x55b32abf1fa8) > ffff8800bda0ff38: ffffffff81cf502a (entry_SYSCALL_64_fastpath+0x18/0xad) > ffff8800bda0ff40: 000055b32abf1fa8 (0x55b32abf1fa8) > ffff8800bda0ff48: ffffffff810dc945 (SyS_rt_sigprocmask+0x5/0x1a0) > ffff8800bda0ff50: ffffffff81cf502a (entry_SYSCALL_64_fastpath+0x18/0xad) Thanks for reporting, I hadn't seen this one yet. The problem is that the unwinder expects the last frame pointer to be at a certain address (0xffff8800bda0ff48 in this case), so it can know that it reached the end. It's confused by the save_mcount_regs macro, which builds some fake frames -- which is good -- but then the last frame is at a different offset than what the unwinder expects. Would it be possible for ftrace to rewrite the stack so that it looks like this instead? > ffff8800bda0ff38: ffff8800bda0ff48 (0xffff8800bda0ff48) > ffff8800bda0ff40: ffffffff810dc945 (SyS_rt_sigprocmask+0x5/0x1a0) > ffff8800bda0ff48: 000055b32abf1fa8 (0x55b32abf1fa8) > ffff8800bda0ff50: ffffffff81cf502a (entry_SYSCALL_64_fastpath+0x18/0xad) In other words it would overwrite the "SyS_rt_sigprocmask+0x5/0x1a0" value on the stack at ffff8800bda0ff48 with the original bp, instead of appending to the existing stack. If you would be ok with such an approach, I could take a stab at it. The alternative would be to change the unwinder, but I would rather avoid having to detect another special case if possible. -- Josh ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: WARNING: kernel stack frame pointer has bad value 2017-04-19 13:44 ` Josh Poimboeuf @ 2017-04-19 14:12 ` Steven Rostedt 2017-04-19 16:38 ` Josh Poimboeuf 0 siblings, 1 reply; 6+ messages in thread From: Steven Rostedt @ 2017-04-19 14:12 UTC (permalink / raw) To: Josh Poimboeuf Cc: LKML, Ingo Molnar, Thomas Gleixner, Andy Lutomirski, H. Peter Anvin On Wed, 19 Apr 2017 08:44:57 -0500 Josh Poimboeuf <jpoimboe@redhat.com> wrote: > On Tue, Apr 18, 2017 at 11:37:14PM -0400, Steven Rostedt wrote: > > Josh, > > > > I'm starting to get a bunch of these warnings, and I'm thinking they > > are false positives. The stack frame error is recorded at a call from > > entry_SYSCALL_64_fastpath, where I would expect the bp to not be valid. > > > > To trigger this, I only need to go into /sys/kernel/debug/tracing and > > echo function > current_tracer then cat trace. Maybe function tracer > > stack frames is messing it up some how, but it always fails at the > > entry call. > > > > Here's the dump; > > > > WARNING: kernel stack frame pointer at ffff8800bda0ff30 in sshd:1090 has bad value 000055b32abf1fa8 > ... > > ffff8800bda0ff20: ffff8800bda0ff30 (0xffff8800bda0ff30) > > ffff8800bda0ff28: ffffffff810dc945 (SyS_rt_sigprocmask+0x5/0x1a0) > > ffff8800bda0ff30: 000055b32abf1fa8 (0x55b32abf1fa8) > > ffff8800bda0ff38: ffffffff81cf502a (entry_SYSCALL_64_fastpath+0x18/0xad) > > ffff8800bda0ff40: 000055b32abf1fa8 (0x55b32abf1fa8) > > ffff8800bda0ff48: ffffffff810dc945 (SyS_rt_sigprocmask+0x5/0x1a0) > > ffff8800bda0ff50: ffffffff81cf502a (entry_SYSCALL_64_fastpath+0x18/0xad) > > Thanks for reporting, I hadn't seen this one yet. > > The problem is that the unwinder expects the last frame pointer to be at > a certain address (0xffff8800bda0ff48 in this case), so it can know that > it reached the end. It's confused by the save_mcount_regs macro, which > builds some fake frames -- which is good -- but then the last frame is > at a different offset than what the unwinder expects. > > Would it be possible for ftrace to rewrite the stack so that it looks > like this instead? > > > ffff8800bda0ff38: ffff8800bda0ff48 (0xffff8800bda0ff48) > > ffff8800bda0ff40: ffffffff810dc945 (SyS_rt_sigprocmask+0x5/0x1a0) > > ffff8800bda0ff48: 000055b32abf1fa8 (0x55b32abf1fa8) > > ffff8800bda0ff50: ffffffff81cf502a (entry_SYSCALL_64_fastpath+0x18/0xad) > > In other words it would overwrite the "SyS_rt_sigprocmask+0x5/0x1a0" > value on the stack at ffff8800bda0ff48 with the original bp, instead of > appending to the existing stack. If you would be ok with such an > approach, I could take a stab at it. This is because we have to handle each different config differently. This is the case with FENTRY and FRAME_POINTERS. As I like to keep this as efficient as possible. To do the above, we need to modify the return address and then restore it. And handle that for each config type. > > The alternative would be to change the unwinder, but I would rather > avoid having to detect another special case if possible. I'm not sure what's worse. Modifying all the special cases of ftrace, or adding a new one to the undwinder. You can take a crack at it if you like, but it needs to be negligible in the performance of FENTRY and no frame pointers. -- Steve ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: WARNING: kernel stack frame pointer has bad value 2017-04-19 14:12 ` Steven Rostedt @ 2017-04-19 16:38 ` Josh Poimboeuf 0 siblings, 0 replies; 6+ messages in thread From: Josh Poimboeuf @ 2017-04-19 16:38 UTC (permalink / raw) To: Steven Rostedt Cc: LKML, Ingo Molnar, Thomas Gleixner, Andy Lutomirski, H. Peter Anvin On Wed, Apr 19, 2017 at 10:12:03AM -0400, Steven Rostedt wrote: > On Wed, 19 Apr 2017 08:44:57 -0500 > Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > > On Tue, Apr 18, 2017 at 11:37:14PM -0400, Steven Rostedt wrote: > > > Josh, > > > > > > I'm starting to get a bunch of these warnings, and I'm thinking they > > > are false positives. The stack frame error is recorded at a call from > > > entry_SYSCALL_64_fastpath, where I would expect the bp to not be valid. > > > > > > To trigger this, I only need to go into /sys/kernel/debug/tracing and > > > echo function > current_tracer then cat trace. Maybe function tracer > > > stack frames is messing it up some how, but it always fails at the > > > entry call. > > > > > > Here's the dump; > > > > > > WARNING: kernel stack frame pointer at ffff8800bda0ff30 in sshd:1090 has bad value 000055b32abf1fa8 > > ... > > > ffff8800bda0ff20: ffff8800bda0ff30 (0xffff8800bda0ff30) > > > ffff8800bda0ff28: ffffffff810dc945 (SyS_rt_sigprocmask+0x5/0x1a0) > > > ffff8800bda0ff30: 000055b32abf1fa8 (0x55b32abf1fa8) > > > ffff8800bda0ff38: ffffffff81cf502a (entry_SYSCALL_64_fastpath+0x18/0xad) > > > ffff8800bda0ff40: 000055b32abf1fa8 (0x55b32abf1fa8) > > > ffff8800bda0ff48: ffffffff810dc945 (SyS_rt_sigprocmask+0x5/0x1a0) > > > ffff8800bda0ff50: ffffffff81cf502a (entry_SYSCALL_64_fastpath+0x18/0xad) > > > > Thanks for reporting, I hadn't seen this one yet. > > > > The problem is that the unwinder expects the last frame pointer to be at > > a certain address (0xffff8800bda0ff48 in this case), so it can know that > > it reached the end. It's confused by the save_mcount_regs macro, which > > builds some fake frames -- which is good -- but then the last frame is > > at a different offset than what the unwinder expects. > > > > Would it be possible for ftrace to rewrite the stack so that it looks > > like this instead? > > > > > ffff8800bda0ff38: ffff8800bda0ff48 (0xffff8800bda0ff48) > > > ffff8800bda0ff40: ffffffff810dc945 (SyS_rt_sigprocmask+0x5/0x1a0) > > > ffff8800bda0ff48: 000055b32abf1fa8 (0x55b32abf1fa8) > > > ffff8800bda0ff50: ffffffff81cf502a (entry_SYSCALL_64_fastpath+0x18/0xad) > > > > In other words it would overwrite the "SyS_rt_sigprocmask+0x5/0x1a0" > > value on the stack at ffff8800bda0ff48 with the original bp, instead of > > appending to the existing stack. If you would be ok with such an > > approach, I could take a stab at it. > > This is because we have to handle each different config differently. > This is the case with FENTRY and FRAME_POINTERS. As I like to keep this > as efficient as possible. To do the above, we need to modify the return > address and then restore it. And handle that for each config type. > > > > > The alternative would be to change the unwinder, but I would rather > > avoid having to detect another special case if possible. > > I'm not sure what's worse. Modifying all the special cases of ftrace, > or adding a new one to the undwinder. > > You can take a crack at it if you like, but it needs to be negligible > in the performance of FENTRY and no frame pointers. How about something like the following (completely untested): diff --git a/arch/x86/kernel/mcount_64.S b/arch/x86/kernel/mcount_64.S index 7b0d3da..54f0f45 100644 --- a/arch/x86/kernel/mcount_64.S +++ b/arch/x86/kernel/mcount_64.S @@ -27,19 +27,19 @@ EXPORT_SYMBOL(mcount) /* All cases save the original rbp (8 bytes) */ #ifdef CONFIG_FRAME_POINTER # ifdef CC_USING_FENTRY -/* Save parent and function stack frames (rip and rbp) */ -# define MCOUNT_FRAME_SIZE (8+16*2) +/* Save extra stack frame (rip and rbp) */ +# define MCOUNT_FRAME_SIZE 16 # else -/* Save just function stack frame (rip and rbp) */ -# define MCOUNT_FRAME_SIZE (8+16) +/* Save just rbp */ +# define MCOUNT_FRAME_SIZE 8 # endif #else /* No need to save a stack frame */ -# define MCOUNT_FRAME_SIZE 8 +# define MCOUNT_FRAME_SIZE 0 #endif /* CONFIG_FRAME_POINTER */ /* Size of stack used to save mcount regs in save_mcount_regs */ -#define MCOUNT_REG_SIZE (SS+8 + MCOUNT_FRAME_SIZE) +#define MCOUNT_REG_SIZE (FRAME_SIZE + MCOUNT_FRAME_SIZE) /* * gcc -pg option adds a call to 'mcount' in most functions. @@ -66,10 +66,7 @@ EXPORT_SYMBOL(mcount) * %rsi - holds the parent function (traced function's return address) * %rdx - holds the original %rbp */ -.macro save_mcount_regs added=0 - - /* Always save the original rbp */ - pushq %rbp +.macro save_mcount_regs save_flags=0 #ifdef CONFIG_FRAME_POINTER /* @@ -80,15 +77,14 @@ EXPORT_SYMBOL(mcount) * is called afterward. */ #ifdef CC_USING_FENTRY - /* Save the parent pointer (skip orig rbp and our return address) */ - pushq \added+8*2(%rsp) - pushq %rbp - movq %rsp, %rbp - /* Save the return address (now skip orig rbp, rbp and parent) */ - pushq \added+8*3(%rsp) -#else - /* Can't assume that rip is before this (unless added was zero) */ - pushq \added+8(%rsp) + /* Copy rip to make room for original rbp */ + pushq (%rsp) + + /* Put original rbp next to parent rip */ + movq %rbp, 8(%rsp) + + /* Make rbp point to original rbp */ + leaq 8(%rsp), %rbp #endif pushq %rbp movq %rsp, %rbp @@ -96,8 +92,19 @@ EXPORT_SYMBOL(mcount) /* * We add enough stack to save all regs. + * + * If saving flags, stop in the middle of the stack adjustment to save + * them in the right spot. Use 'leaq' instead of 'subq' so the flags + * aren't affected. */ - subq $(MCOUNT_REG_SIZE - MCOUNT_FRAME_SIZE), %rsp + .if \save_flags + leaq EFLAGS-FRAME_SIZE+8(%rsp), %rsp + pushfq + subq $EFLAGS, %rsp + .else + subq FRAME_SIZE, %rsp + .endif + movq %rax, RAX(%rsp) movq %rcx, RCX(%rsp) movq %rdx, RDX(%rsp) @@ -105,23 +112,28 @@ EXPORT_SYMBOL(mcount) movq %rdi, RDI(%rsp) movq %r8, R8(%rsp) movq %r9, R9(%rsp) + /* * Save the original RBP. Even though the mcount ABI does not * require this, it helps out callers. */ - movq MCOUNT_REG_SIZE-8(%rsp), %rdx +#ifdef CONFIG_FRAME_POINTER + movq (%rbp), %rdx movq %rdx, RBP(%rsp) +#else + movq %rbp, RBP(%rsp) +#endif /* Copy the parent address into %rsi (second parameter) */ #ifdef CC_USING_FENTRY - movq MCOUNT_REG_SIZE+8+\added(%rsp), %rsi + movq MCOUNT_REG_SIZE+8(%rsp), %rsi #else - /* %rdx contains original %rbp */ + movq RBP(%rsp), %rdx movq 8(%rdx), %rsi #endif /* Move RIP to its proper location */ - movq MCOUNT_REG_SIZE+\added(%rsp), %rdi + movq MCOUNT_REG_SIZE(%rsp), %rdi movq %rdi, RIP(%rsp) /* @@ -132,7 +144,7 @@ EXPORT_SYMBOL(mcount) subq $MCOUNT_INSN_SIZE, %rdi .endm -.macro restore_mcount_regs +.macro restore_mcount_regs restore_flags=0 movq R9(%rsp), %r9 movq R8(%rsp), %r8 movq RDI(%rsp), %rdi @@ -144,7 +156,13 @@ EXPORT_SYMBOL(mcount) /* ftrace_regs_caller can modify %rbp */ movq RBP(%rsp), %rbp + .if \restore_flags + leaq EFLAGS(%rsp), %rsp + popfq + addq FRAME_SIZE-EFLAGS+8, %rsp + .else addq $MCOUNT_REG_SIZE, %rsp + .endif .endm @@ -191,11 +209,7 @@ WEAK(ftrace_stub) END(ftrace_caller) ENTRY(ftrace_regs_caller) - /* Save the current flags before any operations that can change them */ - pushfq - - /* added 8 bytes to save flags */ - save_mcount_regs 8 + save_mcount_regs save_flags=1 /* save_mcount_regs fills in first two parameters */ GLOBAL(ftrace_regs_caller_op_ptr) @@ -210,16 +224,13 @@ GLOBAL(ftrace_regs_caller_op_ptr) movq %r11, R11(%rsp) movq %r10, R10(%rsp) movq %rbx, RBX(%rsp) - /* Copy saved flags */ - movq MCOUNT_REG_SIZE(%rsp), %rcx - movq %rcx, EFLAGS(%rsp) /* Kernel segments */ movq $__KERNEL_DS, %rcx movq %rcx, SS(%rsp) movq $__KERNEL_CS, %rcx movq %rcx, CS(%rsp) - /* Stack - skipping return address and flags */ - leaq MCOUNT_REG_SIZE+8*2(%rsp), %rcx + /* Stack - skipping return address */ + leaq MCOUNT_REG_SIZE+8(%rsp), %rcx movq %rcx, RSP(%rsp) /* regs go into 4th parameter */ @@ -228,10 +239,6 @@ GLOBAL(ftrace_regs_caller_op_ptr) GLOBAL(ftrace_regs_call) call ftrace_stub - /* Copy flags back to SS, to restore them */ - movq EFLAGS(%rsp), %rax - movq %rax, MCOUNT_REG_SIZE(%rsp) - /* Handlers can change the RIP */ movq RIP(%rsp), %rax movq %rax, MCOUNT_REG_SIZE+8(%rsp) @@ -244,10 +251,7 @@ GLOBAL(ftrace_regs_call) movq R10(%rsp), %r10 movq RBX(%rsp), %rbx - restore_mcount_regs - - /* Restore flags */ - popfq + restore_mcount_regs restore_flags=1 /* * As this jmp to ftrace_epilogue can be a short jump ^ permalink raw reply related [flat|nested] 6+ messages in thread
* WARNING: kernel stack frame pointer has bad value @ 2018-04-19 15:57 syzbot 2018-04-19 17:28 ` Dmitry Vyukov 0 siblings, 1 reply; 6+ messages in thread From: syzbot @ 2018-04-19 15:57 UTC (permalink / raw) To: linux-kernel, syzkaller-bugs Hello, syzbot hit the following crash on upstream commit 48023102b7078a6674516b1fe0d639669336049d (Fri Apr 13 23:55:41 2018 +0000) Merge branch 'overlayfs-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=37035ccfa9a0a017ffcf So far this crash happened 141 times on net-next, upstream. C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5871698234572800 syzkaller reproducer: https://syzkaller.appspot.com/x/repro.syz?id=5086177975599104 Raw console output: https://syzkaller.appspot.com/x/log.txt?id=5110926181138432 Kernel config: https://syzkaller.appspot.com/x/.config?id=-8852471259444315113 compiler: gcc (GCC) 8.0.1 20180413 (experimental) IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+37035ccfa9a0a017ffcf@syzkaller.appspotmail.com It will help syzbot understand when the bug is fixed. See footer for details. If you forward the report, please keep this part and the footer. 00000000ed8ccbe7: 0000000000440169 (0x440169) 00000000469f2a79: 0000000000000033 (0x33) 000000004636639d: 0000000000000246 (0x246) 00000000aa65aef8: 00007ffead676158 (0x7ffead676158) 00000000e3ef297c: 000000000000002b (0x2b) WARNING: kernel stack frame pointer at 000000004832711f in syzkaller561281:4479 has bad value 000000006b4f8502 WARNING: kernel stack regs at 0000000089e11b3b in syzkaller561281:4479 has bad 'bp' value 00000000f19a2a3b random: crng init done --- This bug is generated by a dumb bot. It may contain errors. See https://goo.gl/tpsmEJ for details. Direct all questions to syzkaller@googlegroups.com. syzbot will keep track of this bug report. If you forgot to add the Reported-by tag, once the fix for this bug is merged into any tree, please reply to this email with: #syz fix: exact-commit-title If you want to test a patch for this bug, please reply with: #syz test: git://repo/address.git branch and provide the patch inline or as an attachment. To mark this as a duplicate of another syzbot report, please reply with: #syz dup: exact-subject-of-another-report If it's a one-off invalid bug report, please reply with: #syz invalid Note: if the crash happens again, it will cause creation of a new bug report. Note: all commands must start from beginning of the line in the email body. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: WARNING: kernel stack frame pointer has bad value 2018-04-19 15:57 syzbot @ 2018-04-19 17:28 ` Dmitry Vyukov 0 siblings, 0 replies; 6+ messages in thread From: Dmitry Vyukov @ 2018-04-19 17:28 UTC (permalink / raw) To: syzbot, Herbert Xu, David Miller, linux-crypto, Eric Biggers Cc: LKML, syzkaller-bugs On Thu, Apr 19, 2018 at 5:57 PM, syzbot <syzbot+37035ccfa9a0a017ffcf@syzkaller.appspotmail.com> wrote: > Hello, > > syzbot hit the following crash on upstream commit > 48023102b7078a6674516b1fe0d639669336049d (Fri Apr 13 23:55:41 2018 +0000) > Merge branch 'overlayfs-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs > syzbot dashboard link: > https://syzkaller.appspot.com/bug?extid=37035ccfa9a0a017ffcf > > So far this crash happened 141 times on net-next, upstream. > C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5871698234572800 > syzkaller reproducer: > https://syzkaller.appspot.com/x/repro.syz?id=5086177975599104 > Raw console output: > https://syzkaller.appspot.com/x/log.txt?id=5110926181138432 > Kernel config: > https://syzkaller.appspot.com/x/.config?id=-8852471259444315113 > compiler: gcc (GCC) 8.0.1 20180413 (experimental) This seems to be related to keccakf_rndc, please see the "Raw console output" link. +crypto maintainers > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+37035ccfa9a0a017ffcf@syzkaller.appspotmail.com > It will help syzbot understand when the bug is fixed. See footer for > details. > If you forward the report, please keep this part and the footer. > > 00000000ed8ccbe7: 0000000000440169 (0x440169) > 00000000469f2a79: 0000000000000033 (0x33) > 000000004636639d: 0000000000000246 (0x246) > 00000000aa65aef8: 00007ffead676158 (0x7ffead676158) > 00000000e3ef297c: 000000000000002b (0x2b) > WARNING: kernel stack frame pointer at 000000004832711f in > syzkaller561281:4479 has bad value 000000006b4f8502 > WARNING: kernel stack regs at 0000000089e11b3b in syzkaller561281:4479 has > bad 'bp' value 00000000f19a2a3b > random: crng init done > > > --- > This bug is generated by a dumb bot. It may contain errors. > See https://goo.gl/tpsmEJ for details. > Direct all questions to syzkaller@googlegroups.com. > > syzbot will keep track of this bug report. > If you forgot to add the Reported-by tag, once the fix for this bug is > merged > into any tree, please reply to this email with: > #syz fix: exact-commit-title > If you want to test a patch for this bug, please reply with: > #syz test: git://repo/address.git branch > and provide the patch inline or as an attachment. > To mark this as a duplicate of another syzbot report, please reply with: > #syz dup: exact-subject-of-another-report > If it's a one-off invalid bug report, please reply with: > #syz invalid > Note: if the crash happens again, it will cause creation of a new bug > report. > Note: all commands must start from beginning of the line in the email body. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-04-19 17:29 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-04-19 3:37 WARNING: kernel stack frame pointer has bad value Steven Rostedt 2017-04-19 13:44 ` Josh Poimboeuf 2017-04-19 14:12 ` Steven Rostedt 2017-04-19 16:38 ` Josh Poimboeuf 2018-04-19 15:57 syzbot 2018-04-19 17:28 ` Dmitry Vyukov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).