From cc02e6e21aa5f2ac0defe8c15e5a9d024da6e73d Mon Sep 17 00:00:00 2001 From: Alexander Gordeev Date: Fri, 10 Jun 2022 11:04:36 +0200 Subject: s390/crash: add missing iterator advance in copy_oldmem_page() In case old memory was successfully copied the passed iterator should be advanced as well. Currently copy_oldmem_page() is always called with single-segment iterator. Should that ever change - copy_oldmem_user and copy_oldmem_kernel() functions would need a rework to deal with multi-segment iterators. Fixes: 5d8de293c224 ("vmcore: convert copy_oldmem_page() to take an iov_iter") Reviewed-by: Alexander Egorenkov Tested-by: Alexander Egorenkov Signed-off-by: Alexander Gordeev --- arch/s390/kernel/crash_dump.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/arch/s390/kernel/crash_dump.c b/arch/s390/kernel/crash_dump.c index a2c1c55daec0..2534a31d2550 100644 --- a/arch/s390/kernel/crash_dump.c +++ b/arch/s390/kernel/crash_dump.c @@ -219,6 +219,11 @@ ssize_t copy_oldmem_page(struct iov_iter *iter, unsigned long pfn, size_t csize, unsigned long src; int rc; + if (!(iter_is_iovec(iter) || iov_iter_is_kvec(iter))) + return -EINVAL; + /* Multi-segment iterators are not supported */ + if (iter->nr_segs > 1) + return -EINVAL; if (!csize) return 0; src = pfn_to_phys(pfn) + offset; @@ -228,6 +233,8 @@ ssize_t copy_oldmem_page(struct iov_iter *iter, unsigned long pfn, size_t csize, rc = copy_oldmem_user(iter->iov->iov_base, src, csize); else rc = copy_oldmem_kernel(iter->kvec->iov_base, src, csize); + if (!rc) + iov_iter_advance(iter, csize); return rc; } -- cgit v1.2.3-58-ga151 From af2debd58bd769e38f538143f0d332e15d753396 Mon Sep 17 00:00:00 2001 From: Alexander Gordeev Date: Thu, 9 Jun 2022 21:32:39 +0200 Subject: s390/crash: make copy_oldmem_page() return number of bytes copied Callback copy_oldmem_page() returns either error code or zero. Instead, it should return the error code or number of bytes copied. Fixes: df9694c7975f ("s390/dump: streamline oldmem copy functions") Reviewed-by: Alexander Egorenkov Tested-by: Alexander Egorenkov Signed-off-by: Alexander Gordeev --- arch/s390/kernel/crash_dump.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/s390/kernel/crash_dump.c b/arch/s390/kernel/crash_dump.c index 2534a31d2550..28124d0fa1d5 100644 --- a/arch/s390/kernel/crash_dump.c +++ b/arch/s390/kernel/crash_dump.c @@ -233,9 +233,10 @@ ssize_t copy_oldmem_page(struct iov_iter *iter, unsigned long pfn, size_t csize, rc = copy_oldmem_user(iter->iov->iov_base, src, csize); else rc = copy_oldmem_kernel(iter->kvec->iov_base, src, csize); - if (!rc) - iov_iter_advance(iter, csize); - return rc; + if (rc < 0) + return rc; + iov_iter_advance(iter, csize); + return csize; } /* -- cgit v1.2.3-58-ga151 From be857b7f77d130dbbd47c91fc35198b040f35865 Mon Sep 17 00:00:00 2001 From: Thomas Richter Date: Fri, 10 Jun 2022 15:19:00 +0200 Subject: s390/cpumf: Handle events cycles and instructions identical Events CPU_CYCLES and INSTRUCTIONS can be submitted with two different perf_event attribute::type values: - PERF_TYPE_HARDWARE: when invoked via perf tool predefined events name cycles or cpu-cycles or instructions. - pmu->type: when invoked via perf tool event name cpu_cf/CPU_CYLCES/ or cpu_cf/INSTRUCTIONS/. This invocation also selects the PMU to which the event belongs. Handle both type of invocations identical for events CPU_CYLCES and INSTRUCTIONS. They address the same hardware. The result is different when event modifier exclude_kernel is also set. Invocation with event modifier for user space event counting fails. Output before: # perf stat -e cpum_cf/cpu_cycles/u -- true Performance counter stats for 'true': cpum_cf/cpu_cycles/u 0.000761033 seconds time elapsed 0.000076000 seconds user 0.000725000 seconds sys # Output after: # perf stat -e cpum_cf/cpu_cycles/u -- true Performance counter stats for 'true': 349,613 cpum_cf/cpu_cycles/u 0.000844143 seconds time elapsed 0.000079000 seconds user 0.000800000 seconds sys # Fixes: 6a82e23f45fe ("s390/cpumf: Adjust registration of s390 PMU device drivers") Signed-off-by: Thomas Richter Acked-by: Sumanth Korikkar [agordeev@linux.ibm.com corrected commit ID of Fixes commit] Signed-off-by: Alexander Gordeev --- arch/s390/kernel/perf_cpum_cf.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/arch/s390/kernel/perf_cpum_cf.c b/arch/s390/kernel/perf_cpum_cf.c index 483ab5e10164..f7dd3c849e68 100644 --- a/arch/s390/kernel/perf_cpum_cf.c +++ b/arch/s390/kernel/perf_cpum_cf.c @@ -516,6 +516,26 @@ static int __hw_perf_event_init(struct perf_event *event, unsigned int type) return err; } +/* Events CPU_CYLCES and INSTRUCTIONS can be submitted with two different + * attribute::type values: + * - PERF_TYPE_HARDWARE: + * - pmu->type: + * Handle both type of invocations identical. They address the same hardware. + * The result is different when event modifiers exclude_kernel and/or + * exclude_user are also set. + */ +static int cpumf_pmu_event_type(struct perf_event *event) +{ + u64 ev = event->attr.config; + + if (cpumf_generic_events_basic[PERF_COUNT_HW_CPU_CYCLES] == ev || + cpumf_generic_events_basic[PERF_COUNT_HW_INSTRUCTIONS] == ev || + cpumf_generic_events_user[PERF_COUNT_HW_CPU_CYCLES] == ev || + cpumf_generic_events_user[PERF_COUNT_HW_INSTRUCTIONS] == ev) + return PERF_TYPE_HARDWARE; + return PERF_TYPE_RAW; +} + static int cpumf_pmu_event_init(struct perf_event *event) { unsigned int type = event->attr.type; @@ -525,7 +545,7 @@ static int cpumf_pmu_event_init(struct perf_event *event) err = __hw_perf_event_init(event, type); else if (event->pmu->type == type) /* Registered as unknown PMU */ - err = __hw_perf_event_init(event, PERF_TYPE_RAW); + err = __hw_perf_event_init(event, cpumf_pmu_event_type(event)); else return -ENOENT; -- cgit v1.2.3-58-ga151 From 541a496644512ebed429b33f19a3fadfb19c6ee7 Mon Sep 17 00:00:00 2001 From: Thomas Richter Date: Tue, 14 Jun 2022 12:40:46 +0200 Subject: s390/pai: Prevent invalid event number for pai_crypto PMU The pai_crypto PMU has to check the event number. It has to be in the supported range. This is not the case, the lower limit is not checked. Fix this and obey the lower limit. Fixes: 39d62336f5c1 ("s390/pai: add support for cryptography counters") Signed-off-by: Thomas Richter Suggested-by: Sumanth Korikkar Reviewed-by: Sumanth Korikkar Signed-off-by: Alexander Gordeev --- arch/s390/kernel/perf_pai_crypto.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/s390/kernel/perf_pai_crypto.c b/arch/s390/kernel/perf_pai_crypto.c index 8c1545946d85..188c6cf09c7a 100644 --- a/arch/s390/kernel/perf_pai_crypto.c +++ b/arch/s390/kernel/perf_pai_crypto.c @@ -193,8 +193,9 @@ static int paicrypt_event_init(struct perf_event *event) /* PAI crypto PMU registered as PERF_TYPE_RAW, check event type */ if (a->type != PERF_TYPE_RAW && event->pmu->type != a->type) return -ENOENT; - /* PAI crypto event must be valid */ - if (a->config > PAI_CRYPTO_BASE + paicrypt_cnt) + /* PAI crypto event must be in valid range */ + if (a->config < PAI_CRYPTO_BASE || + a->config > PAI_CRYPTO_BASE + paicrypt_cnt) return -EINVAL; /* Allow only CPU wide operation, no process context for now. */ if (event->hw.target || event->cpu == -1) -- cgit v1.2.3-58-ga151 From 21e876448792af2dd5261338907c72bdf37fa056 Mon Sep 17 00:00:00 2001 From: Thomas Richter Date: Wed, 15 Jun 2022 14:02:07 +0200 Subject: s390/pai: Fix multiple concurrent event installation Two different events such as pai_crypto/KM_AES_128/ and pai_crypto/KM_AES_192/ can be installed multiple times on the same CPU and the events are executed concurrently: # perf stat -e pai_crypto/KM_AES_128/ -C0 -a -- sleep 5 & # sleep 2 # perf stat -e pai_crypto/KM_AES_192/ -C0 -a -- true This results in the first event being installed two times with two seconds delay. The kernel does install the second event after the first event has been deleted and re-added, as can be seen in the traces: 13:48:47.600350 paicrypt_start event 0x1007 (event KM_AES_128) 13:48:49.599359 paicrypt_stop event 0x1007 (event KM_AES_128) 13:48:49.599198 paicrypt_start event 0x1007 13:48:49.599199 paicrypt_start event 0x1008 13:48:49.599921 paicrypt_event_destroy event 0x1008 13:48:52.601507 paicrypt_event_destroy event 0x1007 This is caused by functions event_sched_in() and event_sched_out() which call the PMU's add() and start() functions on schedule_in and the PMU's stop() and del() functions on schedule_out. This is correct for events attached to processes. The pai_crypto events are system-wide events and not attached to processes. Since the kernel common code can not be changed easily, fix this issue and do not reset the event count value to zero each time the event is added and started. Instead use a flag and zero the event count value only when called immediately after the event has been initialized. Therefore only the first invocation of the the event's add() function initializes the event count value to zero. The following invocations of the event's add() function leave the current event count value untouched. Fixes: 39d62336f5c1 ("s390/pai: add support for cryptography counters") Reported-by: Sumanth Korikkar Signed-off-by: Thomas Richter Acked-by: Sumanth Korikkar Signed-off-by: Alexander Gordeev --- arch/s390/kernel/perf_pai_crypto.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/arch/s390/kernel/perf_pai_crypto.c b/arch/s390/kernel/perf_pai_crypto.c index 188c6cf09c7a..b38b4ae01589 100644 --- a/arch/s390/kernel/perf_pai_crypto.c +++ b/arch/s390/kernel/perf_pai_crypto.c @@ -209,6 +209,12 @@ static int paicrypt_event_init(struct perf_event *event) if (rc) return rc; + /* Event initialization sets last_tag to 0. When later on the events + * are deleted and re-added, do not reset the event count value to zero. + * Events are added, deleted and re-added when 2 or more events + * are active at the same time. + */ + event->hw.last_tag = 0; cpump->event = event; event->destroy = paicrypt_event_destroy; @@ -243,9 +249,12 @@ static void paicrypt_start(struct perf_event *event, int flags) { u64 sum; - sum = paicrypt_getall(event); /* Get current value */ - local64_set(&event->hw.prev_count, sum); - local64_set(&event->count, 0); + if (!event->hw.last_tag) { + event->hw.last_tag = 1; + sum = paicrypt_getall(event); /* Get current value */ + local64_set(&event->count, 0); + local64_set(&event->hw.prev_count, sum); + } } static int paicrypt_add(struct perf_event *event, int flags) -- cgit v1.2.3-58-ga151