Re: [perf] more perf_fuzzer memory corruption

[Vince Weaver <vincent.weaver@maine.edu>]

On Tue, 29 Apr 2014, Peter Zijlstra wrote:

> > Event #16 is a SW event created and running in the parent on CPU0.
> 
> A regular software one, right? Not a timer one.

Maybe.  From traces I have it looks like it's a regular one (i.e. calls 
 perf_swevent_add() ) but who knows at this point.

When I actually got a trace with perf_event_open() instrumented to print 
some attr values it looked like things were being caused by
PERF_COUNT_SW_TASK_CLOCK which makes no sense.

> > CPU6 (child) shutting down.
> >    last user of event #16
> >    perf_release() called on event
> >    which eventually calls event_sched_out()
> >    which calls pmu->del which removes event from swevent_htable
> >    *but only on CPU6*
> 
> So on fork() we'll also clone the counter; after which there's two. One
> will run on each task.

even if inherit isn't set?

> Because of a context switch optimization they can actually flip around
> (the below patch disables that).

ENOPATCH?

> quite the puzzle this one

yes.

I'm tediously working on trying to get a good trace of this happening.

I have a random seed that will trigger the bug in the fuzzer around 1 time 
in 10.

Unfortunately many of the times it crashes so hard/quickly there's no 
chance of getting the trace data (dump trace on oops never holds enough 
state, and often the fuzzing triggers its own random trace events that 
clutter those logs).

Also trace-cmd is a pain to use.  Any suggested events I should trace 
beyond the obvious?

Part of the problem is that despite what the documentation says it doesn't 
look like you can combine the "-P pid" and "-c" children option, which 
makes debugging a forking problem like this a lot harder to trace.

It's sort of possible to get around that with a really complicated -F ""
command line that does sudo back to me (don't want to fuzz as root) and 
such, but still awkward.

Vince