s390/cpumf: remove counter transaction call backs
The command 'perf stat -e cycles ...' triggers the following function sequence in the CPU Measurement Facility counter device driver: perf_pmu_event_init() __hw_perf_event_init() validate_ctr_auth() validate_ctr_version() During event creation, the counter number is checked in functions validate_ctr_auth() and validate_ctr_version() to verify it is a valid counter and supported by the hardware. If this is not the case, both functions return an error and the event is not created. System call perf_event_open() returns an error in this case. Later on the event is installed in the kernel event subsystem and the driver functions cpumf_pmu_add() and cpumf_pmu_commit_txn() are called to install the counter event by the hardware. Since both events have been verified at event creation, there is no need to re-evaluate the authorization state. This can not change since on * LPARs the authorization change requires a restart of the LPAR (and thus a reboot of the kernel) * DPMs can not take resources away, just add them. Also the sequence of CPU Measurement facility counter device driver calls is cpumf_pmu_start_txn cpumf_pmu_add cpumf_pmu_start cpumf_pmu_commit_txn for every single event. Which means the condition in cpumf_pmu_add() is never met and validate_ctr_auth() is never called. This leaves the counter device driver transaction functions with just one task: start_txn: Verify a transaction is not in flight and call perf_pmu_disable() cancel_txn, commit_txn: Verify a transaction is in flight and call perf_pmu_enable() The same functionality is provided by the default transaction handling functions in kernel/events/core.c. Use those by removing the counter device driver private call back functions. Suggested-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Reviewed-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Showing
Please register or sign in to comment