Re: ptrace: gpf in syscall_trace_enter

2014-05-07 Thread Mathieu Desnoyers
- Original Message - > From: "Steven Rostedt" > To: "Sasha Levin" > Cc: "Oleg Nesterov" , rol...@redhat.com, "LKML" > , "Dave Jones" > , "Mathieu Desnoyers" > Sent: Wednesday, May 7, 2014 12:06:27 PM >

Re: ptrace: gpf in syscall_trace_enter

2014-05-07 Thread Andy Lutomirski
On 05/07/2014 09:06 AM, Steven Rostedt wrote: > [ adding Mathieu as well, as this is tracepoint code ] > > On Wed, 07 May 2014 11:23:36 -0400 > Sasha Levin wrote: > >> On 05/07/2014 10:31 AM, Steven Rostedt wrote: >>> On Wed, 7 May 2014 16:04:22 +0200 >>> Oleg Nesterov wrote: >>> On 05/06,

Re: ptrace: gpf in syscall_trace_enter

2014-05-07 Thread Steven Rostedt
[ adding Mathieu as well, as this is tracepoint code ] On Wed, 07 May 2014 11:23:36 -0400 Sasha Levin wrote: > On 05/07/2014 10:31 AM, Steven Rostedt wrote: > > On Wed, 7 May 2014 16:04:22 +0200 > > Oleg Nesterov wrote: > > > >> On 05/06, Sasha Levin wrote: > >>> > >>> On 05/06/2014 08:36 PM,

Re: ptrace: gpf in syscall_trace_enter

2014-05-07 Thread Steven Rostedt
On Wed, 07 May 2014 11:52:35 -0400 Sasha Levin wrote: > > As the objdump is just of the object files and not the vmlinux, I would > > need the offset from syscall_trace_leave of the RIP. > > 2803: 41 ff 14 24 callq *(%r12) <=== Here > 2807: 49 83 c4 10

Re: ptrace: gpf in syscall_trace_enter

2014-05-07 Thread Sasha Levin
On 05/07/2014 11:49 AM, Steven Rostedt wrote: > On Wed, 7 May 2014 16:04:22 +0200 > Oleg Nesterov wrote: > >> On 05/06, Sasha Levin wrote: >>> >>> On 05/06/2014 08:36 PM, Sasha Levin wrote: Hi all, While fuzzing with trinity inside a KVM tools guest running the latest -next >

Re: ptrace: gpf in syscall_trace_enter

2014-05-07 Thread Steven Rostedt
On Wed, 7 May 2014 16:04:22 +0200 Oleg Nesterov wrote: > On 05/06, Sasha Levin wrote: > > > > On 05/06/2014 08:36 PM, Sasha Levin wrote: > > > Hi all, > > > > > > While fuzzing with trinity inside a KVM tools guest running the latest > > > -next > > > kernel I've stumbled on the following spew:

Re: ptrace: gpf in syscall_trace_enter

2014-05-07 Thread Sasha Levin
On 05/07/2014 10:31 AM, Steven Rostedt wrote: > On Wed, 7 May 2014 16:04:22 +0200 > Oleg Nesterov wrote: > >> On 05/06, Sasha Levin wrote: >>> >>> On 05/06/2014 08:36 PM, Sasha Levin wrote: Hi all, While fuzzing with trinity inside a KVM tools guest running the latest -next >

Re: ptrace: gpf in syscall_trace_enter

2014-05-07 Thread Steven Rostedt
On Wed, 7 May 2014 16:04:22 +0200 Oleg Nesterov wrote: > On 05/06, Sasha Levin wrote: > > > > On 05/06/2014 08:36 PM, Sasha Levin wrote: > > > Hi all, > > > > > > While fuzzing with trinity inside a KVM tools guest running the latest > > > -next > > > kernel I've stumbled on the following spew:

Re: ptrace: gpf in syscall_trace_enter

2014-05-07 Thread Oleg Nesterov
Hi, On 05/06, Sasha Levin wrote: > > Hi all, > > While fuzzing with trinity inside a KVM tools guest running the latest -next > kernel I've stumbled on the following spew: This is not ptrace ;) At first glance, tracepoint->funcs corruption. Add Steven. > [ 3029.100936] general protection fault:

Re: ptrace: gpf in syscall_trace_enter

2014-05-07 Thread Oleg Nesterov
On 05/06, Sasha Levin wrote: > > On 05/06/2014 08:36 PM, Sasha Levin wrote: > > Hi all, > > > > While fuzzing with trinity inside a KVM tools guest running the latest -next > > kernel I've stumbled on the following spew: > > And another similar trace: Again, this looks like __DO_TRACE() trying to

Re: ptrace: gpf in syscall_trace_enter

2014-05-06 Thread Sasha Levin
On 05/06/2014 08:36 PM, Sasha Levin wrote: > Hi all, > > While fuzzing with trinity inside a KVM tools guest running the latest -next > kernel I've stumbled on the following spew: And another similar trace: [ 6897.628729] general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 6897.629

ptrace: gpf in syscall_trace_enter

2014-05-06 Thread Sasha Levin
Hi all, While fuzzing with trinity inside a KVM tools guest running the latest -next kernel I've stumbled on the following spew: [ 3029.100936] general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 3029.102198] Dumping ftrace buffer: [ 3029.102928](ftrace buffer empty) [ 3029.1036