kernel/linux.git/drivers/hwtracing, branch v5.4.113

stm class: Fix module init return on allocation failure

2021-01-27T10:47:50+00:00

commit 927633a6d20af319d986f3e42c3ef9f6d7835008 upstream. In stm_heartbeat_init(): return value gets reset after the first iteration by stm_source_register_device(), so allocation failures after that will, after a clean up, return success. Fix that. Fixes: 119291853038 ("stm class: Add heartbeat stm source device") Reported-by: Hulk Robot Signed-off-by: Wang Hui Signed-off-by: Alexander Shishkin Link: https://lore.kernel.org/r/20210115195917.3184-2-alexander.shishkin@linux.intel.com Cc: stable Signed-off-by: Greg Kroah-Hartman

intel_th: pci: Add Alder Lake-P support

2021-01-27T10:47:49+00:00

commit cb5c681ab9037e25fcca20689c82cf034566d610 upstream. This adds support for the Trace Hub in Alder Lake-P. Signed-off-by: Alexander Shishkin Link: https://lore.kernel.org/r/20210115195917.3184-3-alexander.shishkin@linux.intel.com Cc: stable Signed-off-by: Greg Kroah-Hartman

coresight: etb10: Fix possible NULL ptr dereference in etb_enable_perf()

2020-12-30T10:50:59+00:00

commit 22b2beaa7f166f550424cbb3b988aeaa7ef0425a upstream. There was a report of NULL pointer dereference in ETF enable path for perf CS mode with PID monitoring. It is almost 100% reproducible when the process to monitor is something very active such as chrome and with ETF as the sink, not ETR. But code path shows that ETB has a similar path as ETF, so there could be possible NULL pointer dereference crash in ETB as well. Currently in a bid to find the pid, the owner is dereferenced via task_pid_nr() call in etb_enable_perf() and with owner being NULL, we can get a NULL pointer dereference, so have a similar fix as ETF where we cache PID in alloc_buffer() callback which is called as the part of etm_setup_aux(). Fixes: 75d7dbd38824 ("coresight: etb10: Add support for CPU-wide trace scenarios") Cc: stable@vger.kernel.org Signed-off-by: Sai Prakash Ranjan Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20201127175256.1092685-11-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman

coresight: tmc-etr: Fix barrier packet insertion for perf buffer

2020-12-30T10:50:59+00:00

commit 83be0b84fe846edf0c722fefe225482d5f0d7395 upstream. When the ETR is used in perf mode with a larger buffer (configured via sysfs or the default size of 1M) than the perf aux buffer size, we end up inserting the barrier packet at the wrong offset, while moving the offset forward. i.e, instead of the "new moved offset", we insert it at the current hardware buffer offset. These packets will not be visible as they are never copied and could lead to corruption in the trace decoding side, as the decoder is not aware that it needs to reset the decoding. Fixes: ec13c78d7b45 ("coresight: tmc-etr: Add barrier packets when moving offset forward") Cc: Mathieu Poirier Cc: stable@vger.kernel.org Reported-by: Al Grant Tested-by: Mike Leach Signed-off-by: Suzuki K Poulose Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20201208182651.1597945-2-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman

coresight: tmc-etr: Check if page is valid before dma_map_page()

2020-12-30T10:50:59+00:00

commit 1cc573d5754e92372a7e30e35468644f8811e1a4 upstream. alloc_pages_node() return should be checked before calling dma_map_page() to make sure that valid page is mapped or else it can lead to aborts as below: Unable to handle kernel paging request at virtual address ffffffc008000000 Mem abort info: ... pc : __dma_inv_area+0x40/0x58 lr : dma_direct_map_page+0xd8/0x1c8 Call trace: __dma_inv_area tmc_pages_alloc tmc_alloc_data_pages tmc_alloc_sg_table tmc_init_etr_sg_table tmc_alloc_etr_buf tmc_enable_etr_sink_sysfs tmc_enable_etr_sink coresight_enable_path coresight_enable enable_source_store dev_attr_store sysfs_kf_write Fixes: 99443ea19e8b ("coresight: Add generic TMC sg table framework") Cc: stable@vger.kernel.org Reviewed-by: Suzuki K Poulose Signed-off-by: Mao Jinlong Signed-off-by: Sai Prakash Ranjan Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20201127175256.1092685-13-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman

coresight: tmc-etf: Fix NULL ptr dereference in tmc_enable_etf_sink_perf()

2020-12-30T10:50:59+00:00

commit 868663dd5d69fef05bfb004f91da5c30e9b93461 upstream. There was a report of NULL pointer dereference in ETF enable path for perf CS mode with PID monitoring. It is almost 100% reproducible when the process to monitor is something very active such as chrome and with ETF as the sink and not ETR. Currently in a bid to find the pid, the owner is dereferenced via task_pid_nr() call in tmc_enable_etf_sink_perf() and with owner being NULL, we get a NULL pointer dereference. Looking at the ETR and other places in the kernel, ETF and the ETB are the only places trying to dereference the task(owner) in tmc_enable_etf_sink_perf() which is also called from the sched_in path as in the call trace. Owner(task) is NULL even in the case of ETR in tmc_enable_etr_sink_perf(), but since we cache the PID in alloc_buffer() callback and it is done as part of etm_setup_aux() when allocating buffer for ETR sink, we never dereference this NULL pointer and we are safe. So lets do the same thing with ETF and cache the PID to which the cs_buffer belongs in tmc_alloc_etf_buffer() as done for ETR. This will also remove the unnecessary function calls(task_pid_nr()) since we are caching the PID. Easily reproducible running below: perf record -e cs_etm/@tmc_etf0/ -N -p Unable to handle kernel NULL pointer dereference at virtual address 0000000000000548 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 ... Call trace: tmc_enable_etf_sink+0xe4/0x280 coresight_enable_path+0x168/0x1fc etm_event_start+0x8c/0xf8 etm_event_add+0x38/0x54 event_sched_in+0x194/0x2ac group_sched_in+0x54/0x12c flexible_sched_in+0xd8/0x120 visit_groups_merge+0x100/0x16c ctx_flexible_sched_in+0x50/0x74 ctx_sched_in+0xa4/0xa8 perf_event_sched_in+0x60/0x6c perf_event_context_sched_in+0x98/0xe0 __perf_event_task_sched_in+0x5c/0xd8 finish_task_switch+0x184/0x1cc schedule_tail+0x20/0xec ret_from_fork+0x4/0x18 Fixes: 880af782c6e8 ("coresight: tmc-etf: Add support for CPU-wide trace scenarios") Cc: stable@vger.kernel.org Signed-off-by: Sai Prakash Ranjan Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20201127175256.1092685-10-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman

Revert "coresight: Make sysfs functional on topologies with per core sink"

2020-11-10T11:37:31+00:00

This reverts commit 8fd52a21ab570e80f84f39e12affce42a5300e91. Guenter Roeck writes: I get the following build warning in v5.4.75. drivers/hwtracing/coresight/coresight-etm-perf.c: In function 'etm_setup_aux': drivers/hwtracing/coresight/coresight-etm-perf.c:226:37: warning: passing argument 1 of 'coresight_get_enabled_sink' makes pointer from integer without a cast Actually, the warning is fatal, since the call is sink = coresight_get_enabled_sink(true); However, the argument to coresight_get_enabled_sink() is now a pointer. The parameter change was introduced with commit 8fd52a21ab57 ("coresight: Make sysfs functional on topologies with per core sink"). In the upstream kernel, the call is removed with commit bb1860efc817 ("coresight: etm: perf: Sink selection using sysfs is deprecated"). That commit alone would, however, likely not solve the problem. It looks like at least two more commits would be needed. 716f5652a131 coresight: etm: perf: Fix warning caused by etm_setup_aux failure 8e264c52e1da coresight: core: Allow the coresight core driver to be built as a module 39a7661dcf65 coresight: Fix uninitialised pointer bug in etm_setup_aux() Looking into the coresight code, I see several additional commits affecting the sysfs interface since v5.4. I have no idea what would actually be needed for stable code in v5.4.y, short of applying them all. With all this in mind, I would suggest to revert commit 8fd52a21ab57 ("coresight: Make sysfs functional on topologies with per core sink") from v5.4.y, especially since it is not marked as bug fix or for stable. Signed-off-by: Sasha Levin

coresight: Make sysfs functional on topologies with per core sink

2020-11-05T10:43:18+00:00

[ Upstream commit 6d578258b955fc8888e1bbd9a8fefe7b10065a84 ] Coresight driver assumes sink is common across all the ETMs, and tries to build a path between ETM and the first enabled sink found using bus based search. This breaks sysFS usage on implementations that has multiple per core sinks in enabled state. To fix this, coresight_get_enabled_sink API is updated to do a connection based search starting from the given source, instead of bus based search. With sink selection using sysfs depecrated for perf interface, provision for reset is removed as well in this API. Signed-off-by: Linu Cherian [Fixed indentation problem and removed obsolete comment] Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200916191737.4001561-15-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

coresight: etm: perf: Fix warning caused by etm_setup_aux failure

2020-10-29T08:57:43+00:00

[ Upstream commit 716f5652a13122364a65e694386b9b26f5e98c51 ] When coresight_build_path() fails on all the cpus, etm_setup_aux calls etm_free_aux() to free allocated event_data. WARN_ON(cpumask_empty(mask) will be triggered since cpu mask is empty. Check event_data->snk_config is not NULL first to avoid this warning. Fixes: f5200aa9831f38 ("coresight: perf: Refactor function free_event_data()") Reviewed-by: Mike Leach Reviewed-by: Suzuki K Poulose Signed-off-by: Tingwei Zhang Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200928163513.70169-9-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

coresight: etm4x: Handle unreachable sink in perf mode

2020-10-29T08:57:40+00:00

[ Upstream commit 859d510e58dac94f0b204b7b5cccafbc130d2291 ] If the specified/hinted sink is not reachable from a subset of the CPUs, we could end up unable to trace the event on those CPUs. This is the best effort we could do until we support 1:1 configurations. Fail gracefully in such cases avoiding a WARN_ON, which can be easily triggered by the user on certain platforms (Arm N1SDP), with the following trace paths : CPU0 \ -- Funnel0 --> ETF0 --> / \ CPU1 \ MainFunnel CPU2 / \ / -- Funnel1 --> ETF1 --> / CPU1 $ perf record --per-thread -e cs_etm/@ETF0/u -- could trigger the following WARNING, when the event is scheduled on CPU2. [10919.513250] ------------[ cut here ]------------ [10919.517861] WARNING: CPU: 2 PID: 24021 at drivers/hwtracing/coresight/coresight-etm-perf.c:316 etm_event_start+0xf8/0x100 ... [10919.564403] CPU: 2 PID: 24021 Comm: perf Not tainted 5.8.0+ #24 [10919.570308] pstate: 80400089 (Nzcv daIf +PAN -UAO BTYPE=--) [10919.575865] pc : etm_event_start+0xf8/0x100 [10919.580034] lr : etm_event_start+0x80/0x100 [10919.584202] sp : fffffe001932f940 [10919.587502] x29: fffffe001932f940 x28: fffffc834995f800 [10919.592799] x27: 0000000000000000 x26: fffffe0011f3ced0 [10919.598095] x25: fffffc837fce244c x24: fffffc837fce2448 [10919.603391] x23: 0000000000000002 x22: fffffc8353529c00 [10919.608688] x21: fffffc835bb31000 x20: 0000000000000000 [10919.613984] x19: fffffc837fcdcc70 x18: 0000000000000000 [10919.619281] x17: 0000000000000000 x16: 0000000000000000 [10919.624577] x15: 0000000000000000 x14: 00000000000009f8 [10919.629874] x13: 00000000000009f8 x12: 0000000000000018 [10919.635170] x11: 0000000000000000 x10: 0000000000000000 [10919.640467] x9 : fffffe00108cd168 x8 : 0000000000000000 [10919.645763] x7 : 0000000000000020 x6 : 0000000000000001 [10919.651059] x5 : 0000000000000002 x4 : 0000000000000001 [10919.656356] x3 : 0000000000000000 x2 : 0000000000000000 [10919.661652] x1 : fffffe836eb40000 x0 : 0000000000000000 [10919.666949] Call trace: [10919.669382] etm_event_start+0xf8/0x100 [10919.673203] etm_event_add+0x40/0x60 [10919.676765] event_sched_in.isra.134+0xcc/0x210 [10919.681281] merge_sched_in+0xb0/0x2a8 [10919.685017] visit_groups_merge.constprop.140+0x15c/0x4b8 [10919.690400] ctx_sched_in+0x15c/0x170 [10919.694048] perf_event_sched_in+0x6c/0xa0 [10919.698130] ctx_resched+0x60/0xa0 [10919.701517] perf_event_exec+0x288/0x2f0 [10919.705425] begin_new_exec+0x4c8/0xf58 [10919.709247] load_elf_binary+0x66c/0xf30 [10919.713155] exec_binprm+0x15c/0x450 [10919.716716] __do_execve_file+0x508/0x748 [10919.720711] __arm64_sys_execve+0x40/0x50 [10919.724707] do_el0_svc+0xf4/0x1b8 [10919.728095] el0_sync_handler+0xf8/0x124 [10919.732003] el0_sync+0x140/0x180 Even though we don't support using separate sinks for the ETMs yet (e.g, for 1:1 configurations), we should at least honor the user's choice and handle the limitations gracefully, by simply skipping the tracing on ETMs which can't reach the requested sink. Fixes: f9d81a657bb8 ("coresight: perf: Allow tracing on hotplugged CPUs") Cc: Mathieu Poirier Cc: Mike Leach Reported-by: Jeremy Linton Tested-by: Jeremy Linton Signed-off-by: Suzuki K Poulose Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200916191737.4001561-11-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin