From: tom.leiming@gmail.com (Ming Lei)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/4] ARM: perf: check that we have an event in the PMU IRQ handlers
Date: Fri, 24 Feb 2012 09:34:32 +0800 [thread overview]
Message-ID: <CACVXFVM6HOMeJCMznLqO6-jMT8owoK65Ap6c_CNCJbwWxphCBA@mail.gmail.com> (raw)
In-Reply-To: <1330012696-13472-4-git-send-email-will.deacon@arm.com>
Hi,
On Thu, Feb 23, 2012 at 11:58 PM, Will Deacon <will.deacon@arm.com> wrote:
> The PMU IRQ handlers in perf assume that if a counter has overflowed
> then perf must be responsible. In the paranoid world of crazy hardware,
> this could be false, so check that we do have a valid event before
> attempting to dereference NULL in the interrupt path.
>
> Signed-off-by: Ming Lei <tom.leiming@gmail.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> ?arch/arm/kernel/perf_event_v6.c ? ? | ? 20 ++------------------
> ?arch/arm/kernel/perf_event_v7.c ? ? | ? ?4 ++++
> ?arch/arm/kernel/perf_event_xscale.c | ? ?6 ++++++
> ?3 files changed, 12 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/kernel/perf_event_v6.c b/arch/arm/kernel/perf_event_v6.c
> index 88bf152..b78af0c 100644
> --- a/arch/arm/kernel/perf_event_v6.c
> +++ b/arch/arm/kernel/perf_event_v6.c
> @@ -467,23 +467,6 @@ armv6pmu_enable_event(struct hw_perf_event *hwc,
> ? ? ? ?raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
> ?}
>
> -static int counter_is_active(unsigned long pmcr, int idx)
> -{
> - ? ? ? unsigned long mask = 0;
> - ? ? ? if (idx == ARMV6_CYCLE_COUNTER)
> - ? ? ? ? ? ? ? mask = ARMV6_PMCR_CCOUNT_IEN;
> - ? ? ? else if (idx == ARMV6_COUNTER0)
> - ? ? ? ? ? ? ? mask = ARMV6_PMCR_COUNT0_IEN;
> - ? ? ? else if (idx == ARMV6_COUNTER1)
> - ? ? ? ? ? ? ? mask = ARMV6_PMCR_COUNT1_IEN;
> -
> - ? ? ? if (mask)
> - ? ? ? ? ? ? ? return pmcr & mask;
> -
> - ? ? ? WARN_ONCE(1, "invalid counter number (%d)\n", idx);
> - ? ? ? return 0;
> -}
> -
> ?static irqreturn_t
> ?armv6pmu_handle_irq(int irq_num,
> ? ? ? ? ? ? ? ? ? ?void *dev)
> @@ -513,7 +496,8 @@ armv6pmu_handle_irq(int irq_num,
> ? ? ? ? ? ? ? ?struct perf_event *event = cpuc->events[idx];
> ? ? ? ? ? ? ? ?struct hw_perf_event *hwc;
>
> - ? ? ? ? ? ? ? if (!counter_is_active(pmcr, idx))
> + ? ? ? ? ? ? ? /* Ignore if we don't have an event. */
> + ? ? ? ? ? ? ? if (!event)
I think we should check it via test_bit(idx, cpuc->used_mask) because
'hw_events->events[idx] = val' is not atomic operation and it is read here
in irq context.
> ? ? ? ? ? ? ? ? ? ? ? ?continue;
>
> ? ? ? ? ? ? ? ?/*
> diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
> index 050cc8b..4d7095a 100644
> --- a/arch/arm/kernel/perf_event_v7.c
> +++ b/arch/arm/kernel/perf_event_v7.c
> @@ -960,6 +960,10 @@ static irqreturn_t armv7pmu_handle_irq(int irq_num, void *dev)
> ? ? ? ? ? ? ? ?struct perf_event *event = cpuc->events[idx];
> ? ? ? ? ? ? ? ?struct hw_perf_event *hwc;
>
> + ? ? ? ? ? ? ? /* Ignore if we don't have an event. */
> + ? ? ? ? ? ? ? if (!event)
Same with above.
> + ? ? ? ? ? ? ? ? ? ? ? continue;
> +
> ? ? ? ? ? ? ? ?/*
> ? ? ? ? ? ? ? ? * We have a single interrupt for all counters. Check that
> ? ? ? ? ? ? ? ? * each counter has overflowed before we process it.
> diff --git a/arch/arm/kernel/perf_event_xscale.c b/arch/arm/kernel/perf_event_xscale.c
> index 831e019..a5bbd36 100644
> --- a/arch/arm/kernel/perf_event_xscale.c
> +++ b/arch/arm/kernel/perf_event_xscale.c
> @@ -255,6 +255,9 @@ xscale1pmu_handle_irq(int irq_num, void *dev)
> ? ? ? ? ? ? ? ?struct perf_event *event = cpuc->events[idx];
> ? ? ? ? ? ? ? ?struct hw_perf_event *hwc;
>
> + ? ? ? ? ? ? ? if (!event)
Same with above.
> + ? ? ? ? ? ? ? ? ? ? ? continue;
> +
> ? ? ? ? ? ? ? ?if (!xscale1_pmnc_counter_has_overflowed(pmnc, idx))
> ? ? ? ? ? ? ? ? ? ? ? ?continue;
>
> @@ -592,6 +595,9 @@ xscale2pmu_handle_irq(int irq_num, void *dev)
> ? ? ? ? ? ? ? ?struct perf_event *event = cpuc->events[idx];
> ? ? ? ? ? ? ? ?struct hw_perf_event *hwc;
>
> + ? ? ? ? ? ? ? if (!event)
Same with above.
> + ? ? ? ? ? ? ? ? ? ? ? continue;
> +
> ? ? ? ? ? ? ? ?if (!xscale2_pmnc_counter_has_overflowed(pmnc, idx))
> ? ? ? ? ? ? ? ? ? ? ? ?continue;
>
> --
> 1.7.4.1
>
thanks,
--
Ming Lei
next prev parent reply other threads:[~2012-02-24 1:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-23 15:58 [PATCH 0/4] perf IRQ fixes Will Deacon
2012-02-23 15:58 ` [PATCH 1/4] ARM: perf: limit sample_period to half max_period in non-sampling mode Will Deacon
2012-02-23 15:58 ` [PATCH 2/4] ARM: perf: clear overflow flag when disabling counter on ARMv7 PMU Will Deacon
2012-02-24 2:05 ` Ming Lei
2012-02-23 15:58 ` [PATCH 3/4] ARM: perf: check that we have an event in the PMU IRQ handlers Will Deacon
2012-02-24 1:34 ` Ming Lei [this message]
2012-02-24 10:11 ` Will Deacon
2012-02-27 9:56 ` Ming Lei
2012-02-27 19:36 ` Will Deacon
2012-02-28 0:53 ` Ming Lei
2012-02-28 10:55 ` Will Deacon
2012-02-28 14:28 ` Ming Lei
2012-02-23 15:58 ` [PATCH 4/4] ARM: perf: fix overflow handling for xscale2 PMUs Will Deacon
2012-03-07 9:41 ` [PATCH 0/4] perf IRQ fixes Russell King - ARM Linux
2012-03-07 9:44 ` Will Deacon
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=CACVXFVM6HOMeJCMznLqO6-jMT8owoK65Ap6c_CNCJbwWxphCBA@mail.gmail.com \
--to=tom.leiming@gmail.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).