On Wed, Sep 10, 2014 at 10:30:31AM -0400, Vince Weaver wrote: > On Wed, 10 Sep 2014, Sasha Levin wrote: > > > On 09/10/2014 09:18 AM, Vince Weaver wrote: > > > that's what got me looking at things again, the trinity reports. Though > > > I > > > think those involve CPU hotplugging which my fuzzer shouldn't trigger. > > > > > > I do think this is the same memory corruption/reboot bug that I reported > > > back in February (the thread is "perf_fuzzer compiled for x32 causes > > > reboot" but I wasn't able to isolate the problem then either. > > > > > > Somehow something is stomping over memory with a forking workload (likely > > > an improper free with RCU like we've seen before) but the fact that it > > > causes a reboot immediately makes it *really* hard to debug this. > > > > Could this be http://permalink.gmane.org/gmane.linux.kernel/1779436 which > > I saw couple days ago? > > It could be. > > I have about 10 open bugs with similar symptoms found with my perf_fuzzer > here (and a few more that are possibly the same memory corruption bug that > "fixes" went into the kernel but it's unclear if it actually fixed things > or just altered the locking enough to make it harder to hit). > > > http://web.eece.maine.edu/~vweaver/projects/perf_events/fuzzer/bugs_found.html > > I've been trying for months now to make progress on these but this type of > bug is really hard to debug.
Did we actually fix some at least? I had the idea we did get a few sorted. But yes, this is tedious and hard going :/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
