OK, humor me a bit here.
I'm looking at the buggy trace and comparing against a "good" trace where
the bug doesn't happen.
It is a rance condition of sorts, because it's just a 10us or so
interleaving of calls that causes the bug to happen or not.
In the good trace:
[parent] __perf_event_task_sched_out (and hence perf_swevent_del)
[child] perf_release
In the buggy trace:
[child] perf_release
[parent] __perf_event_task_sched_out (perf_swevent_del never happens)
perf_swevent_del calls
hlist_del_rcu(event->hlist_entry)
to remove the event from the swevent hlist.
Now in theory perf_release() calls sw_perf_event_destroy() which you
would think would also call the above. Instead it does
swevent_hlist_put_cpu(event, cpu);
which does all kinds of weird hash stuff that I don't follow.
Should the above two be equivelent? Is it reference counting in there
with if (!--swhash->hlist_refcount) causing the issue?
Anyway I'm tired of staring at traces for the moment.
Vince
--
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/
