From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] perf evsel: Fix to perf-stat malloc corruption on arm64 platforms
Date: Wed, 26 Apr 2017 15:50:57 +0100 [thread overview]
Message-ID: <20170426145057.GK27156@leverpostej> (raw)
In-Reply-To: <1493198780-25415-1-git-send-email-ganapatrao.kulkarni@cavium.com>
Hi Ganapatrao,
Thanks for tracking this down.
On Wed, Apr 26, 2017 at 02:56:20PM +0530, Ganapatrao Kulkarni wrote:
> In some cases, ncpus used for perf_evsel__alloc_fd and for
> perf_evsel__close are not the same, this is causing memory
> overwrite/corruption.
It would be good if we could enumerate when this occurs.
>From what I can tell, the problem occurs when opening a thread-bound
event on PMU with a cpus/cpumask in sysfs.
For perf-stat we create events using create_perf_stat_counter(). There
we see !target_has_cpu(), so we call perf_evsel__open_per_thread(). Thus
perf_evsel__open() is passed NULL cpus, and creates an empty cpu_map. As
cpus->nr = 1, we get 1 * nthreads fds allocated, and open events for
each of these.
Later, we try to close events using perf_evlist__close(). This doesn't
take target_has_cpu() into account, but sees evsel->cpus is non-NULL
(since the PMU had a cpus/cpumask file), and tries to close events for
cpus->nr * nthreads, and goes out-of-bounds of the fd array.
>
> Fixing issue by using same ncpus in perf_evsel__alloc_fd.
>
> This bug is more evident on arm64 platforms, which uses
> cpu_map(cpus) for PMU core devices.
>
> Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
> ---
> tools/perf/util/evsel.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> index ac59710..0dc94d7 100644
> --- a/tools/perf/util/evsel.c
> +++ b/tools/perf/util/evsel.c
> @@ -1489,7 +1489,9 @@ int perf_evsel__open(struct perf_evsel *evsel, struct cpu_map *cpus,
> nthreads = threads->nr;
>
> if (evsel->fd == NULL &&
> - perf_evsel__alloc_fd(evsel, cpus->nr, nthreads) < 0)
> + perf_evsel__alloc_fd(evsel,
> + evsel->cpus ? evsel->cpus->nr : cpus->nr,
> + nthreads) < 0)
Unfortunately, I don't think this is the right fix.
Looking@the logic I added in commit:
9f21b815be863218 ("perf evlist: Only open events on CPUs an evsel permit").
... in some cases (e.g. when using perf record with cpu-bound events),
evsel->cpus may contain a subset of evlist->cpus, and thus the use of
evsel->cpus->nr here may lower the number of entries allocated, such
that the manipulation of fds will go out-of-bounds.
I think that to properly solve this, we need a more invasive rework,
ensuring that open/manipulation/close always deal with the same set of
cpus and threads for a given evsel.
I'm taking a look into that now.
Thanks,
Mark.
next prev parent reply other threads:[~2017-04-26 14:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-26 9:26 [PATCH] perf evsel: Fix to perf-stat malloc corruption on arm64 platforms Ganapatrao Kulkarni
2017-04-26 14:50 ` Mark Rutland [this message]
2017-04-26 17:12 ` Mark Rutland
2017-04-26 18:19 ` Ganapatrao Kulkarni
2017-04-27 14:34 ` Mark Rutland
2017-04-27 15:46 ` Ganapatrao Kulkarni
2017-04-27 15:52 ` Mark Rutland
2017-04-27 17:24 ` Ganapatrao Kulkarni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170426145057.GK27156@leverpostej \
--to=mark.rutland@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).