On Mon, Apr 28, 2014 at 10:21:34AM -0400, Vince Weaver wrote: > so it's looking more and more like this issue is with a > PERF_COUNT_SW_TASK_CLOCK > event.
But they don't actually use the hlist thing.. > It's being deallocated in a different process than it was started (due to > fork). > > And it really looks like the problem is even though the event is free'd, > there's still an active hrtimer associated with it somehow. So this is a different problem from the hlist corruption? > I can't seem to find *why* there's an associated hrtimer though, as the > event as far as I can tell was created with sample_period=0 and the > various > perf_swevent_init_hrtimer() > calls seem to guard with is_sampling() That is indeed, decidedly odd. > This is made all the more confusing because the PERF_COUNT_SW_TASK_CLOCK > events are handled by their own PMU even though it's faked up so they look > like regular software events. Is there a reason for that? This was the easiest route when we introduced the mulitple pmu thing or so, its been on the todo list for a cleanup ever since :-/ -- 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/
