coresight: Fixes for v5.2-rc5
cover coresight: Fixes for v5.2-rc5
As requested here is a set to fix problems found up to now in this cycle, supplemented with stable tags where applicable.
Thanks,
Mathieu
Dan Carpenter (1):
coresight: Potential uninitialized variable in probe()
Suzuki K Poulose (4):
coresight: tmc-etr: Do not call smp_processor_id() from preemptible
coresight: tmc-etr: alloc_perf_buf: Do not call smp_processor_id from
preemptible
coresight: tmc-etf: Do not call smp_processor_id from preemptible
coresight: etb10: Do not call smp_processor_id from preemptible
drivers/hwtracing/coresight/coresight-etb10.c | 6 ++---- drivers/hwtracing/coresight/coresight-funnel.c | 1 + drivers/hwtracing/coresight/coresight-tmc-etf.c | 6 ++---- drivers/hwtracing/coresight/coresight-tmc-etr.c | 13 ++++--------- 4 files changed, 9 insertions(+), 17 deletions(-)
Signature · 7 lines
2.17.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 1/5 coresight: tmc-etr: Do not call smp_processor_id() from preemptible
From: Suzuki K Poulose <[email protected]>
During a perf session we try to allocate buffers on the "node" associated with the CPU the event is bound to. If it's not bound to a CPU, we use the current CPU node, using smp_processor_id(). However this is unsafe in a pre-emptible context and could generate the splats as below :
BUG: using smp_processor_id() in preemptible [00000000] code: perf/1743 caller is alloc_etr_buf.isra.6+0x80/0xa0 CPU: 1 PID: 1743 Comm: perf Not tainted 5.1.0-rc6-147786-g116841e #344 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb 1 2019 Call trace: dump_backtrace+0x0/0x150 show_stack+0x14/0x20 dump_stack+0x9c/0xc4 debug_smp_processor_id+0x10c/0x110 alloc_etr_buf.isra.6+0x80/0xa0 tmc_alloc_etr_buffer+0x12c/0x1f0 etm_setup_aux+0x1c4/0x230 rb_alloc_aux+0x1b8/0x2b8 perf_mmap+0x35c/0x478 mmap_region+0x34c/0x4f0 do_mmap+0x2d8/0x418 vm_mmap_pgoff+0xd0/0xf8 ksys_mmap_pgoff+0x88/0xf8 __arm64_sys_mmap+0x28/0x38 el0_svc_handler+0xd8/0x138 el0_svc+0x8/0xc
Use NUMA_NO_NODE hint instead of using the current node for events not bound to CPUs.
--- drivers/hwtracing/coresight/coresight-tmc-etr.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
drivers/hwtracing/coresight/coresight-tmc-etr.c +2 -4
@@ -1317,13 +1317,11 @@ static struct etr_perf_buffer * tmc_etr_setup_perf_buf(struct tmc_drvdata *drvdata, struct perf_event *event, int nr_pages, void **pages, bool snapshot) { - int node, cpu = event->cpu; + int node;struct etr_buf *etr_buf;struct etr_perf_buffer *etr_perf; -if (cpu ==-1 ) - cpu =smp_processor_id (); - node =cpu_to_node (cpu); + node = (event->cpu ==-1 ) ?NUMA_NO_NODE :cpu_to_node (event->cpu); etr_perf =kzalloc_node (sizeof (*etr_perf),GFP_KERNEL , node);if (!etr_perf)
Signature · 7 lines
2.17.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 1/5] coresight: tmc-etr: Do not call smp_processor_id() from preemptible
Quoted 29 lines · Mathieu Poirier
From: Suzuki K Poulose <[email protected]>
During a perf session we try to allocate buffers on the "node" associated with the CPU the event is bound to. If it's not bound to a CPU, we use the current CPU node, using
smp_processor_id(). However this is unsafe in a pre-emptible context and could generate the splats as below :BUG: using smp_processor_id() in preemptible [00000000] code: perf/1743 caller is alloc_etr_buf.isra.6+0x80/0xa0 CPU: 1 PID: 1743 Comm: perf Not tainted 5.1.0-rc6-147786-g116841e #344 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb 1 2019 Call trace: dump_backtrace+0x0/0x150 show_stack+0x14/0x20 dump_stack+0x9c/0xc4 debug_smp_processor_id+0x10c/0x110 alloc_etr_buf.isra.6+0x80/0xa0 tmc_alloc_etr_buffer+0x12c/0x1f0 etm_setup_aux+0x1c4/0x230 rb_alloc_aux+0x1b8/0x2b8 perf_mmap+0x35c/0x478 mmap_region+0x34c/0x4f0 do_mmap+0x2d8/0x418 vm_mmap_pgoff+0xd0/0xf8 ksys_mmap_pgoff+0x88/0xf8 __arm64_sys_mmap+0x28/0x38 el0_svc_handler+0xd8/0x138 el0_svc+0x8/0xc
Quoted 4 lines
Use
NUMA_NO_NODEhint instead of using the current node for events not bound to CPUs.Fixes 855ab61c16bf70b646 ("coresight: tmc-etr: Refactor function tmc_etr_setup_perf_buf()")
This should be:
Add:
[core] abbrev = 12
to your .gitconfig file, we only need 12 in the kernel tree. For now :)
thanks,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 2/5 coresight: tmc-etr: alloc_perf_buf: Do not call smp_processor_id from preemptible
In reply to Mathieu PoirierFrom: Suzuki K Poulose <[email protected]>
During a perf session we try to allocate buffers on the "node" associated with the CPU the event is bound to. If it is not bound to a CPU, we use the current CPU node, using smp_processor_id(). However this is unsafe in a pre-emptible context and could generate the splats as below :
BUG: using smp_processor_id() in preemptible [00000000] code: perf/1743 caller is tmc_alloc_etr_buffer+0x1bc/0x1f0 CPU: 1 PID: 1743 Comm: perf Not tainted 5.1.0-rc6-147786-g116841e #344 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb 1 2019 Call trace: dump_backtrace+0x0/0x150 show_stack+0x14/0x20 dump_stack+0x9c/0xc4 debug_smp_processor_id+0x10c/0x110 tmc_alloc_etr_buffer+0x1bc/0x1f0 etm_setup_aux+0x1c4/0x230 rb_alloc_aux+0x1b8/0x2b8 perf_mmap+0x35c/0x478 mmap_region+0x34c/0x4f0 do_mmap+0x2d8/0x418 vm_mmap_pgoff+0xd0/0xf8 ksys_mmap_pgoff+0x88/0xf8 __arm64_sys_mmap+0x28/0x38 el0_svc_handler+0xd8/0x138 el0_svc+0x8/0xc
Use NUMA_NO_NODE hint instead of using the current node for events not bound to CPUs.
--- drivers/hwtracing/coresight/coresight-tmc-etr.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-)
drivers/hwtracing/coresight/coresight-tmc-etr.c +2 -5
@@ -1178,14 +1178,11 @@ static struct etr_buf * alloc_etr_buf(struct tmc_drvdata *drvdata, struct perf_event *event, int nr_pages, void **pages, bool snapshot) { - int node, cpu = event->cpu; + int node;struct etr_buf *etr_buf;unsigned long size; -if (cpu ==-1 ) - cpu =smp_processor_id (); - node =cpu_to_node (cpu); - + node = (event->cpu ==-1 ) ?NUMA_NO_NODE :cpu_to_node (event->cpu);/* * Try to match the perf ring buffer size if it is larger * than the size requested via sysfs.
Signature · 7 lines
2.17.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 3/5 coresight: tmc-etf: Do not call smp_processor_id from preemptible
In reply to Mathieu PoirierFrom: Suzuki K Poulose <[email protected]>
During a perf session we try to allocate buffers on the "node" associated with the CPU the event is bound to. If it is not bound to a CPU, we use the current CPU node, using smp_processor_id(). However this is unsafe in a pre-emptible context and could generate the splats as below :
BUG: using smp_processor_id() in preemptible [00000000] code: perf/2544 caller is tmc_alloc_etf_buffer+0x5c/0x60 CPU: 2 PID: 2544 Comm: perf Not tainted 5.1.0-rc6-147786-g116841e #344 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb 1 2019 Call trace: dump_backtrace+0x0/0x150 show_stack+0x14/0x20 dump_stack+0x9c/0xc4 debug_smp_processor_id+0x10c/0x110 tmc_alloc_etf_buffer+0x5c/0x60 etm_setup_aux+0x1c4/0x230 rb_alloc_aux+0x1b8/0x2b8 perf_mmap+0x35c/0x478 mmap_region+0x34c/0x4f0 do_mmap+0x2d8/0x418 vm_mmap_pgoff+0xd0/0xf8 ksys_mmap_pgoff+0x88/0xf8 __arm64_sys_mmap+0x28/0x38 el0_svc_handler+0xd8/0x138 el0_svc+0x8/0xc
Use NUMA_NO_NODE hint instead of using the current node for events not bound to CPUs.
--- drivers/hwtracing/coresight/coresight-tmc-etf.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
drivers/hwtracing/coresight/coresight-tmc-etf.c +2 -4
@@ -378,12 +378,10 @@ static void *tmc_alloc_etf_buffer(struct coresight_device *csdev, struct perf_event *event, void **pages, int nr_pages, bool overwrite) { - int node, cpu = event->cpu; + int node;struct cs_buffers *buf; -if (cpu ==-1 ) - cpu =smp_processor_id (); - node =cpu_to_node (cpu); + node = (event->cpu ==-1 ) ?NUMA_NO_NODE :cpu_to_node (event->cpu);/* Allocate memory structure for interaction with Perf */ buf =kzalloc_node (sizeof (struct cs_buffers ),GFP_KERNEL , node);
Signature · 7 lines
2.17.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 4/5 coresight: etb10: Do not call smp_processor_id from preemptible
In reply to Mathieu PoirierFrom: Suzuki K Poulose <[email protected]>
During a perf session we try to allocate buffers on the "node" associated with the CPU the event is bound to. If it is not bound to a CPU, we use the current CPU node, using smp_processor_id(). However this is unsafe in a pre-emptible context and could generate the splats as below :
BUG: using smp_processor_id() in preemptible [00000000] code: perf/2544
Use NUMA_NO_NODE hint instead of using the current node for events not bound to CPUs.
--- drivers/hwtracing/coresight/coresight-etb10.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
drivers/hwtracing/coresight/coresight-etb10.c +2 -4
@@ -373,12 +373,10 @@ static void *etb_alloc_buffer(struct coresight_device *csdev, struct perf_event *event, void **pages, int nr_pages, bool overwrite) { - int node, cpu = event->cpu; + int node;struct cs_buffers *buf; -if (cpu ==-1 ) - cpu =smp_processor_id (); - node =cpu_to_node (cpu); + node = (event->cpu ==-1 ) ?NUMA_NO_NODE :cpu_to_node (event->cpu); buf =kzalloc_node (sizeof (struct cs_buffers ),GFP_KERNEL , node);if (!buf)
Signature · 7 lines
2.17.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 5/5 coresight: Potential uninitialized variable in probe()
In reply to Mathieu PoirierFrom: Dan Carpenter <[email protected]>
The "drvdata->atclk" clock is optional, but if it gets set to an error pointer then we're accidentally return an uninitialized variable instead of success.
--- drivers/hwtracing/coresight/coresight-funnel.c | 1 + 1 file changed, 1 insertion(+)
drivers/hwtracing/coresight/coresight-funnel.c +1 -0
@@ -241,6 +241,7 @@ static int funnel_probe(struct device *dev, struct resource *res) }pm_runtime_put (dev); + ret =0 ; out_disable_clk:if (ret && !IS_ERR_OR_NULL (drvdata->atclk))
Signature · 7 lines
2.17.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Greg,
Quoted 3 lines · Mathieu Poirier
As requested here is a set to fix problems found up to now in this cycle, supplemented with stable tags where applicable.
I haven't heard back from this set nor can I find the patches in any of your trees. Given the late state in the cycle I'm not sure what to do, i.e should I do a resend of this set or send you another series to go in the 5.3 merge window - please advise.
Quoted 14 lines
Thanks,
MathieuDan Carpenter (1):
coresight: Potential uninitialized variable inprobe()Suzuki K Poulose (4):
coresight: tmc-etr: Do not callsmp_processor_id()from preemptible
coresight: tmc-etr:alloc_perf_buf: Do not callsmp_processor_idfrom
preemptible
coresight: tmc-etf: Do not callsmp_processor_idfrom preemptible
coresight: etb10: Do not callsmp_processor_idfrom preemptible
Quoted 9 lines
drivers/hwtracing/coresight/coresight-etb10.c | 6 ++---- drivers/hwtracing/coresight/coresight-funnel.c | 1 + drivers/hwtracing/coresight/coresight-tmc-etf.c | 6 ++---- drivers/hwtracing/coresight/coresight-tmc-etr.c | 13 ++++--------- 4 files changed, 9 insertions(+), 17 deletions(-)--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 5 lines · Mathieu Poirier
Hi Greg,
Quoted 1 line · Mathieu Poirier
Quoted 7 lines
Quoted 2 lines
As requested here is a set to fix problems found up to now in this cycle, supplemented with stable tags where applicable.
I haven't heard back from this set nor can I find the patches in any of your trees. Given the late state in the cycle I'm not sure what to do, i.e should I do a resend of this set or send you another series to go in the 5.3 merge window - please advise.
I'll take these for 5.3-rc1 and if anything needs to go in 5.2, we can backport them to stable then.
thanks,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel