Re: workaround/blacklist/exclude perf?

Re: workaround/blacklist/exclude perf?

[Toralf Förster]

tfoerste@n22 ~/Downloads/BL $ ssh root@trinity "trinity --help"
trinity
 --children,-C: specify number of child processes
 --exclude,-x: don't call a specific syscall



-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

workaround/blacklist/exclude perf?

[Mikko Rapeli]

Is there some simple trick to exclude a single test case which produces
an oops?

I'm hitting one of the perf issues after few minutes but would like to
continue testing other kernel subsystems.

-Mikko

Re: workaround/blacklist/exclude perf?

[Dave Jones]

On Tue, Oct 08, 2013 at 06:22:09PM +0300, Mikko Rapeli wrote:
 > Is there some simple trick to exclude a single test case which produces
 > an oops?
 > 
 > I'm hitting one of the perf issues after few minutes but would like to
 > continue testing other kernel subsystems.

The perf bugs are nasty.  You can try -x perf_event_open, (and also edit
open_perf_fds in perf.c to just return instantly, but in my experience even
with this, somehow we still end up triggering perf stuff. I've no explanation for it.

	Dave

Re: workaround/blacklist/exclude perf?

[Mikko Rapeli]

On Tue, Oct 08, 2013 at 01:31:59PM -0400, Dave Jones wrote:
> On Tue, Oct 08, 2013 at 06:22:09PM +0300, Mikko Rapeli wrote:
>  > Is there some simple trick to exclude a single test case which produces
>  > an oops?
>  > 
>  > I'm hitting one of the perf issues after few minutes but would like to
>  > continue testing other kernel subsystems.
> 
> The perf bugs are nasty.  You can try -x perf_event_open, (and also edit
> open_perf_fds in perf.c to just return instantly, but in my experience even
> with this, somehow we still end up triggering perf stuff. I've no explanation for it.

Thanks, trying this but will follow the lkml thread
( https://lkml.org/lkml/2013/10/8/527 ) too if there's something more that
can be done.

-Mikko

Re: workaround/blacklist/exclude perf?

[Vince Weaver]

On Wed, 9 Oct 2013, Mikko Rapeli wrote:

> On Tue, Oct 08, 2013 at 01:31:59PM -0400, Dave Jones wrote:
>
> > The perf bugs are nasty.  You can try -x perf_event_open, (and also edit
> > open_perf_fds in perf.c to just return instantly, but in my experience even
> > with this, somehow we still end up triggering perf stuff. I've no explanation for it.
> 
> Thanks, trying this but will follow the lkml thread
> ( https://lkml.org/lkml/2013/10/8/527 ) too if there's something more that
> can be done.

For what it's worth, I've been pounding on one of my machines with my 
perf_fuzzer generating traces to try to get a small reproducible test case 
for these bugs.  

It's tricky as even when I find a random seed that triggers things early 
and record a trace, it only triggers the bug on replay maybe 1 in 5 times.  
Which makes any sort of bisection hard :(

Also I keep turning up bugs in my fuzzer due to sillyness in the 
perf_event interface.  I wasted a whole day figuring out that
  a). perf_event_open lets you specify any size for the size field
      as long as it's between 64 and 4096
  b). however, if the value is larger than the kernel expects you
      better have all zeros as padding. (good luck if you allocated
      the struct on the stack and so have leftover garbage at replay
      that wasn't there at record)
  c). if you don't have the right size, the kernel will helpfully 
      over-write your "size" field with its own idea of the size field, 
      so if you try to print things to see what's wrong after the fact 
      you'll always get a good value and pull your hair out trying to 
      figure out what is going on.

Also it returns E2BIG if the value is too small.  Fun times.

Vince