summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorAnand K Mistry <amistry@google.com>2021-09-29 10:04:21 +0300
committerPeter Zijlstra <peterz@infradead.org>2021-10-01 14:57:54 +0300
commit02d029a41dc986e2d5a77ecca45803857b346829 (patch)
tree70434a4e4ac3048800851eca69bb0d5d230895f3 /include
parente4e737bb5c170df6135a127739a9e6148ee3da82 (diff)
downloadlinux-02d029a41dc986e2d5a77ecca45803857b346829.tar.xz
perf/x86: Reset destroy callback on event init failure
perf_init_event tries multiple init callbacks and does not reset the event state between tries. When x86_pmu_event_init runs, it unconditionally sets the destroy callback to hw_perf_event_destroy. On the next init attempt after x86_pmu_event_init, in perf_try_init_event, if the pmu's capabilities includes PERF_PMU_CAP_NO_EXCLUDE, the destroy callback will be run. However, if the next init didn't set the destroy callback, hw_perf_event_destroy will be run (since the callback wasn't reset). Looking at other pmu init functions, the common pattern is to only set the destroy callback on a successful init. Resetting the callback on failure tries to replicate that pattern. This was discovered after commit f11dd0d80555 ("perf/x86/amd/ibs: Extend PERF_PMU_CAP_NO_EXCLUDE to IBS Op") when the second (and only second) run of the perf tool after a reboot results in 0 samples being generated. The extra run of hw_perf_event_destroy results in active_events having an extra decrement on each perf run. The second run has active_events == 0 and every subsequent run has active_events < 0. When active_events == 0, the NMI handler will early-out and not record any samples. Signed-off-by: Anand K Mistry <amistry@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20210929170405.1.I078b98ee7727f9ae9d6df8262bad7e325e40faf0@changeid
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions