WARNING: kernel stack frame pointer has bad value

WARNING: kernel stack frame pointer has bad value

[Steven Rostedt]

[-- 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 --]

Re: WARNING: kernel stack frame pointer has bad value

[Josh Poimboeuf]

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

Re: WARNING: kernel stack frame pointer has bad value

[Steven Rostedt]

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

Re: WARNING: kernel stack frame pointer has bad value

[Josh Poimboeuf]

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

Re: WARNING: kernel stack frame pointer has bad value

[Dmitry Vyukov]

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.

WARNING: kernel stack frame pointer has bad value

[syzbot]

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.