Re: tracing ring_buffer_resize oops.

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 2012-05-24 at 16:53 -0700, H. Peter Anvin wrote:

> Much more fundamentally, RIP should never leave the range [-2G, 0).
> What is happening here is almost certainly that we jump through
> something which isn't a function pointer.
> 
> The other thing worth noting is that the code segment is not the
> standard Linux code segment, not even close; it *also* doesn't look like
> the typical Xen code segment.  This makes be believe that we did an IRET
> with the stack pointer set to something other than a valid interrupt
> stack frame.

I was thinking the same. But not from an NMI. Seems it may be a
breakpoint IRET that is the issue. Could also be a nesting issue with
the stack, as breakpoints have a single stack as well.

I may modify the code a little to see if I can trigger it on a normal
config. Right now, I can only trigger it with an allmodconfig. That may
also be the issue. It may have added some debugging that causes
something to be traced (and breakpoint added) that isn't normally
traced.


>   Specifically, note that the value of R12 is the same
> value; R12 is a preserved register and may have been pushed onto the
> stack by something that wants to save it.

I don't see R12 as the same value:

RIP: <ffff88014630a000>
GS: ffff880148000000
R12: ffff880145cc0000

Close but not quite. Even R13 and R15 are close:

R13: ffff880148008eb8
R15: ffff88014780cb40

But this probably does show that the stack is screwed up and did a bad
iret.

-- Steve