Re: perf_fuzzer compiled for x32 causes reboot

[Steven Rostedt <rostedt@goodmis.org>]

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