lkml.org 
[lkml]   [2014]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: perf_fuzzer compiled for x32 causes reboot
On Fri, 28 Feb 2014 12:34:05 -0800
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:

> On Thu, Feb 27, 2014 at 08:00:04PM -0500, Vince Weaver wrote:
> > On Thu, 27 Feb 2014, H. Peter Anvin wrote:
> >
> > > On 02/27/2014 03:30 PM, Steven Rostedt wrote:
> > > > On Thu, 27 Feb 2014 14:52:54 -0800
> > > > "H. Peter Anvin" <hpa@zytor.com> wrote:
> > > >
> > > >> On 02/27/2014 02:31 PM, Steven Rostedt wrote:
> > > >>>
> > > >>> Yeah, something is getting mesed up.
> > > >>>
> > > >>
> > > >> What it *looks* like to me is that we try to nest the cr2 save/restore,
> > > >> which doesn't nest because it is a percpu variable.
> > > >>
> > > >> ... except in the x86-64 case, we *ALSO* save/restore cr2 inside
> > > >> entry_64.S, which makes the stuff in do_nmi completely redundant and
> > > >> there for no good reason.
> > > >
> > > > Peter, look at the code. That percpu cr2 is in a #ifdef CONFIG_X86_32
> > > > section. That is, it isn't even executed. That's i386 code. The only
> > > > place the cr2 is saved for x86_64 is in entry_64.S.
> > > >
> > >
> > > Right, egg on my face. However, I still think it would make more sense
> > > for it to nest the way entry_64.S does if at all possible.
> > >
> > > That makes this even more confusing, though. I would still like to see
> > > what happens with the patch I sent Vince.
> >
> > I'll try your patch momentarily, first I had some other changes I started
> > running before I left work (for some reason it recompiled the whole
> > kernel).
> >
> > 8: function: perf_output_begin
> > 8: bprint: perf_output_begin: VMW: event type 2 config 2a st: 2c3e
> > 8: bputs: perf_output_begin: VMW: before rcu_dereference
> > 9: function: __do_page_fault
> > 9: function: down_read_trylock
> > 9: function: _cond_resched
> > 9: function: find_vma
> >
> > so it looks like the fault happens
> >
> > rcu_read_lock();
> >
> > 116 /*
> > 117 * For inherited events we send all the output towards the parent.
> > 118 */
> > 119 if (event->parent)
> > 120 event = event->parent;
> > 121
> >
> > somewhere between here
> >
> > 122 rb = rcu_dereference(event->rb);
> > 123 if (unlikely(!rb))
> > 124 goto out;
> >
> > and here
> >
> > 125
> > 126 if (unlikely(!rb->nr_pages))
> > 127 goto out;
> >
> > although if rcu locks do anything to turn off tracing then this could be
> > suspect.
>
> The most likely suspect is of course event->rb in the rcu_dereference.
> I have to defer to Steven on how rcu_read_lock() and rcu_read_unlock()
> currently interact with tracing. ;-)

These are all perf related. You'll need to defer to Peter Zijlstra ;-)

-- Steve


\
 
 \ /
  Last update: 2014-02-28 22:21    [W:0.083 / U:0.536 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site