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 -- To unsubscribe from this list: send the line "unsubscribe trinity" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
