[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1404291407180.22490@vincent-weaver-1.umelst.maine.edu>
Date: Tue, 29 Apr 2014 14:11:09 -0400 (EDT)
From: Vince Weaver <vincent.weaver@...ne.edu>
To: Peter Zijlstra <peterz@...radead.org>
cc: Vince Weaver <vincent.weaver@...ne.edu>,
Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
Thomas Gleixner <tglx@...utronix.de>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [perf] more perf_fuzzer memory corruption
On Tue, 29 Apr 2014, Peter Zijlstra wrote:
> 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..
yes.
This turns out into another issue that I think is just use-after-free
memory corruption exhibiting itself a different way.
I've documented at least 8 different types of error message that I think
are all due to this issue.
> So this is a different problem from the hlist corruption?
Who knows. That's why I'm trying to get this issue fixed so I can figure
out which of the 10+ other bugs I'm tracking are the same or different.
> > 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 :-/
It was very confusing and poorly documented, as is much of the perf_event
files. And yes, I know, I should do something about it rather than
complain.
I've actually given up on source code inspection to figure out what's
going on in kernel/events/core.c. What I do now is write simple test
cases and do an ftrace function trace. The results are often surprising.
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