[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1405011443410.19874@vincent-weaver-1.umelst.maine.edu>
Date: Thu, 1 May 2014 14:49:01 -0400 (EDT)
From: Vince Weaver <vincent.weaver@...ne.edu>
To: Vince Weaver <vincent.weaver@...ne.edu>
cc: Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [perf] more perf_fuzzer memory corruption
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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists