Commit:
ccbebba4c6bf ("perf/x86/intel/pt: Bypass PT vs. LBR exclusivity if the core supports it")
skips the PT/LBR exclusivity check on CPUs where PT and LBRs coexist, but
also inadvertently skips the active_events bump for PT in that case, which
is a bug. If there aren't any hardware events at the same time as PT, the
PMI handler will ignore PT PMIs, as active_events reads zero in that case,
resulting in the "Uhhuh" spurious NMI warning and PT data loss.
Fix this by always increasing active_events for PT events.
Signed-off-by: Alexander Shishkin <[email protected]>
Fixes: ccbebba4c6bf ("perf/x86/intel/pt: Bypass PT vs. LBR exclusivity if the core supports it")
Reported-by: Vitaly Slobodskoy <[email protected]>
Cc: [email protected] # v4.7
---
arch/x86/events/core.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 6e3f0c18908e..5a736197dfa4 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -375,7 +375,7 @@ int x86_add_exclusive(unsigned int what)
* LBR and BTS are still mutually exclusive.
*/
if (x86_pmu.lbr_pt_coexist && what == x86_lbr_exclusive_pt)
- return 0;
+ goto out;
if (!atomic_inc_not_zero(&x86_pmu.lbr_exclusive[what])) {
mutex_lock(&pmc_reserve_mutex);
@@ -387,6 +387,7 @@ int x86_add_exclusive(unsigned int what)
mutex_unlock(&pmc_reserve_mutex);
}
+out:
atomic_inc(&active_events);
return 0;
@@ -397,11 +398,15 @@ int x86_add_exclusive(unsigned int what)
void x86_del_exclusive(unsigned int what)
{
+ atomic_dec(&active_events);
+
+ /*
+ * See the comment in x86_add_exclusive().
+ */
if (x86_pmu.lbr_pt_coexist && what == x86_lbr_exclusive_pt)
return;
atomic_dec(&x86_pmu.lbr_exclusive[what]);
- atomic_dec(&active_events);
}
int x86_setup_perfctr(struct perf_event *event)
--
2.24.0
On 10.12.2019 13:51, Alexander Shishkin wrote:
> Commit:
>
> ccbebba4c6bf ("perf/x86/intel/pt: Bypass PT vs. LBR exclusivity if the core supports it")
>
> skips the PT/LBR exclusivity check on CPUs where PT and LBRs coexist, but
> also inadvertently skips the active_events bump for PT in that case, which
> is a bug. If there aren't any hardware events at the same time as PT, the
> PMI handler will ignore PT PMIs, as active_events reads zero in that case,
> resulting in the "Uhhuh" spurious NMI warning and PT data loss.
>
> Fix this by always increasing active_events for PT events.
>
> Signed-off-by: Alexander Shishkin <[email protected]>
> Fixes: ccbebba4c6bf ("perf/x86/intel/pt: Bypass PT vs. LBR exclusivity if the core supports it")
> Reported-by: Vitaly Slobodskoy <[email protected]>
> Cc: [email protected] # v4.7
> ---
> arch/x86/events/core.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
Acked-by: Alexey Budankov <[email protected]>
>
> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> index 6e3f0c18908e..5a736197dfa4 100644
> --- a/arch/x86/events/core.c
> +++ b/arch/x86/events/core.c
> @@ -375,7 +375,7 @@ int x86_add_exclusive(unsigned int what)
> * LBR and BTS are still mutually exclusive.
> */
> if (x86_pmu.lbr_pt_coexist && what == x86_lbr_exclusive_pt)
> - return 0;
> + goto out;
>
> if (!atomic_inc_not_zero(&x86_pmu.lbr_exclusive[what])) {
> mutex_lock(&pmc_reserve_mutex);
> @@ -387,6 +387,7 @@ int x86_add_exclusive(unsigned int what)
> mutex_unlock(&pmc_reserve_mutex);
> }
>
> +out:
> atomic_inc(&active_events);
> return 0;
>
> @@ -397,11 +398,15 @@ int x86_add_exclusive(unsigned int what)
>
> void x86_del_exclusive(unsigned int what)
> {
> + atomic_dec(&active_events);
> +
> + /*
> + * See the comment in x86_add_exclusive().
> + */
> if (x86_pmu.lbr_pt_coexist && what == x86_lbr_exclusive_pt)
> return;
>
> atomic_dec(&x86_pmu.lbr_exclusive[what]);
> - atomic_dec(&active_events);
> }
>
> int x86_setup_perfctr(struct perf_event *event)
>