From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> To: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: mike.leach@linaro.org, mathieu.poirier@linaro.org, leo.yan@linaro.org, alexander.shishkin@linux.intel.com, swboyd@chromium.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org Subject: Re: [RFC PATCH] coresight: dynamic-replicator: Fix handling of multiple connections Date: Tue, 07 Apr 2020 19:26:45 +0530 [thread overview] Message-ID: <bd05b31c2391edfff5044f22f2f83edf@codeaurora.org> (raw) In-Reply-To: <bb209f80-ac02-6321-dac4-ebf9ee6fa9a0@arm.com> Hi Suzuki, On 2020-04-07 18:38, Suzuki K Poulose wrote: > On 04/07/2020 12:29 PM, Sai Prakash Ranjan wrote: >> Hi Suzuki, >> >> Thanks for looking into this issue. >> >> On 2020-04-07 15:54, Suzuki K Poulose wrote: >>> On 04/07/2020 10:46 AM, Sai Prakash Ranjan wrote: >>> >>> There seems to be two replicators back to back here. What is >>> connected >>> to the other output of both of them ? Are there any TPIUs ? What >>> happens >>> if you choose a sink on the other end of "swao_replicator" (ETB ?) >>> >> >> The other outport of swao replicator is connected to EUD which is a >> QCOM specific HW which can be used as a sink like USB. >> And the other outport of other replicator(replicator_out) is connected >> to >> TPIU. >> >>> After boot, what do the idfilter registers read for both the >>> replicators ? >>> >> >> Added some prints in replicator_probe. >> >> replicator probe ret=-517 devname=6046000.replicator idfilter0=0x0 >> idfilter1=0x0 >> replicator probe ret=0 devname=6b06000.replicator idfilter0=0xff >> idfilter1=0xff >> replicator probe ret=0 devname=6046000.replicator idfilter0=0xff >> idfilter1=0xff > > Curious to see how the idfilterX is set to 0: > if that is never used. > Or > if the user doesn't reset it back to 0xff. > For both replicators, the default value seems to be 0x0. replicator probe in res ret=0 devname=6046000.replicator idfilter0=0x0 idfilter1=0x0 replicator probe ret=-517 devname=6046000.replicator idfilter0=0x0 idfilter1=0x0 replicator probe in res ret=0 devname=6b06000.replicator idfilter0=0x0 idfilter1=0x0 replicator probe ret=0 devname=6b06000.replicator idfilter0=0xff idfilter1=0xff replicator probe in res ret=0 devname=6046000.replicator idfilter0=0x0 idfilter1=0x0 replicator probe ret=0 devname=6046000.replicator idfilter0=0xff idfilter1=0xff > Does your test ever touch EUD (enable the port for EUD at > swao-replicator) ? What are the values before you run your test ? > > No, we do not use EUD, downstream it is used as dummy sink. And I just try to select the ETR as the sink and enable ETM0 as the trace source. echo 1 > /sys/bus/coresight/devices/tmc_etr0/enable_sink echo 1 > /sys/bus/coresight/devices/etm0/enable_source Also I see the KASAN warning but that seems like some other issue. [ 526.110401] ================================================================== [ 526.117988] BUG: KASAN: slab-out-of-bounds in funnel_enable+0x54/0x1b0 [ 526.124706] Read of size 4 at addr ffffff8135f9549c by task bash/1114 [ 526.131324] [ 526.132886] CPU: 3 PID: 1114 Comm: bash Tainted: G S 5.4.25 #232 [ 526.140397] Hardware name: Qualcomm Technologies, Inc. SC7180 IDP (DT) [ 526.147113] Call trace: [ 526.149653] dump_backtrace+0x0/0x188 [ 526.153431] show_stack+0x20/0x2c [ 526.156852] dump_stack+0xdc/0x144 [ 526.160370] print_address_description+0x3c/0x494 [ 526.165211] __kasan_report+0x144/0x168 [ 526.169170] kasan_report+0x10/0x18 [ 526.172769] check_memory_region+0x1a4/0x1b4 [ 526.177164] __kasan_check_read+0x18/0x24 [ 526.181292] funnel_enable+0x54/0x1b0 [ 526.185072] coresight_enable_path+0x104/0x198 [ 526.189649] coresight_enable+0x118/0x26c [ 526.193778] enable_source_store+0x64/0xa8 [ 526.198007] dev_attr_store+0x40/0x58 [ 526.201788] sysfs_kf_write+0x4c/0x64 [ 526.205567] kernfs_fop_write+0x16c/0x210 [ 526.209700] __vfs_write+0x54/0x1a8 [ 526.213297] vfs_write+0xe4/0x1a4 [ 526.216714] ksys_write+0x84/0xec [ 526.220131] __arm64_sys_write+0x20/0x2c [ 526.224179] el0_svc_common+0xa8/0x160 [ 526.228040] el0_svc_compat_handler+0x2c/0x38 [ 526.232533] el0_svc_compat+0x8/0x10 [ 526.236225] [ 526.237782] Allocated by task 280: [ 526.241298] __kasan_kmalloc+0xf0/0x1ac [ 526.245249] kasan_kmalloc+0xc/0x14 [ 526.248849] __kmalloc+0x28c/0x3b4 [ 526.252361] coresight_register+0x88/0x250 [ 526.256587] funnel_probe+0x15c/0x228 [ 526.260365] dynamic_funnel_probe+0x20/0x2c [ 526.264679] amba_probe+0xbc/0x158 [ 526.268193] really_probe+0x144/0x408 [ 526.271970] driver_probe_device+0x70/0x140 [ 526.276282] __device_attach_driver+0x9c/0x110 [ 526.280861] bus_for_each_drv+0x90/0xd8 [ 526.284822] __device_attach+0xb4/0x164 [ 526.288772] device_initial_probe+0x20/0x2c [ 526.293081] bus_probe_device+0x34/0x94 [ 526.297030] deferred_probe_work_func+0xa4/0x100 [ 526.301794] process_one_work+0x33c/0x640 [ 526.305922] worker_thread+0x2a0/0x470 [ 526.309786] kthread+0x128/0x138 [ 526.313119] ret_from_fork+0x10/0x18 [ 526.316810] [ 526.318364] Freed by task 0: [ 526.321344] (stack is not available) [ 526.325024] [ 526.326580] The buggy address belongs to the object at ffffff8135f95480 [ 526.326580] which belongs to the cache kmalloc-128 of size 128 [ 526.339439] The buggy address is located 28 bytes inside of [ 526.339439] 128-byte region [ffffff8135f95480, ffffff8135f95500) [ 526.351399] The buggy address belongs to the page: [ 526.356342] page:ffffffff04b7e500 refcount:1 mapcount:0 mapping:ffffff814b00c380 index:0x0 compound_mapcount: 0 [ 526.366711] flags: 0x4000000000010200(slab|head) [ 526.371475] raw: 4000000000010200 ffffffff05034008 ffffffff0501eb08 ffffff814b00c380 [ 526.379435] raw: 0000000000000000 0000000000190019 00000001ffffffff 0000000000000000 [ 526.387393] page dumped because: kasan: bad access detected [ 526.393128] [ 526.394681] Memory state around the buggy address: [ 526.399619] ffffff8135f95380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 526.407046] ffffff8135f95400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 526.414473] >ffffff8135f95480: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 526.421900] ^ [ 526.426029] ffffff8135f95500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 526.433456] ffffff8135f95580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 526.440883] ================================================================== Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
WARNING: multiple messages have this Message-ID (diff)
From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> To: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: mathieu.poirier@linaro.org, alexander.shishkin@linux.intel.com, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, swboyd@chromium.org, leo.yan@linaro.org, linux-arm-kernel@lists.infradead.org, mike.leach@linaro.org Subject: Re: [RFC PATCH] coresight: dynamic-replicator: Fix handling of multiple connections Date: Tue, 07 Apr 2020 19:26:45 +0530 [thread overview] Message-ID: <bd05b31c2391edfff5044f22f2f83edf@codeaurora.org> (raw) In-Reply-To: <bb209f80-ac02-6321-dac4-ebf9ee6fa9a0@arm.com> Hi Suzuki, On 2020-04-07 18:38, Suzuki K Poulose wrote: > On 04/07/2020 12:29 PM, Sai Prakash Ranjan wrote: >> Hi Suzuki, >> >> Thanks for looking into this issue. >> >> On 2020-04-07 15:54, Suzuki K Poulose wrote: >>> On 04/07/2020 10:46 AM, Sai Prakash Ranjan wrote: >>> >>> There seems to be two replicators back to back here. What is >>> connected >>> to the other output of both of them ? Are there any TPIUs ? What >>> happens >>> if you choose a sink on the other end of "swao_replicator" (ETB ?) >>> >> >> The other outport of swao replicator is connected to EUD which is a >> QCOM specific HW which can be used as a sink like USB. >> And the other outport of other replicator(replicator_out) is connected >> to >> TPIU. >> >>> After boot, what do the idfilter registers read for both the >>> replicators ? >>> >> >> Added some prints in replicator_probe. >> >> replicator probe ret=-517 devname=6046000.replicator idfilter0=0x0 >> idfilter1=0x0 >> replicator probe ret=0 devname=6b06000.replicator idfilter0=0xff >> idfilter1=0xff >> replicator probe ret=0 devname=6046000.replicator idfilter0=0xff >> idfilter1=0xff > > Curious to see how the idfilterX is set to 0: > if that is never used. > Or > if the user doesn't reset it back to 0xff. > For both replicators, the default value seems to be 0x0. replicator probe in res ret=0 devname=6046000.replicator idfilter0=0x0 idfilter1=0x0 replicator probe ret=-517 devname=6046000.replicator idfilter0=0x0 idfilter1=0x0 replicator probe in res ret=0 devname=6b06000.replicator idfilter0=0x0 idfilter1=0x0 replicator probe ret=0 devname=6b06000.replicator idfilter0=0xff idfilter1=0xff replicator probe in res ret=0 devname=6046000.replicator idfilter0=0x0 idfilter1=0x0 replicator probe ret=0 devname=6046000.replicator idfilter0=0xff idfilter1=0xff > Does your test ever touch EUD (enable the port for EUD at > swao-replicator) ? What are the values before you run your test ? > > No, we do not use EUD, downstream it is used as dummy sink. And I just try to select the ETR as the sink and enable ETM0 as the trace source. echo 1 > /sys/bus/coresight/devices/tmc_etr0/enable_sink echo 1 > /sys/bus/coresight/devices/etm0/enable_source Also I see the KASAN warning but that seems like some other issue. [ 526.110401] ================================================================== [ 526.117988] BUG: KASAN: slab-out-of-bounds in funnel_enable+0x54/0x1b0 [ 526.124706] Read of size 4 at addr ffffff8135f9549c by task bash/1114 [ 526.131324] [ 526.132886] CPU: 3 PID: 1114 Comm: bash Tainted: G S 5.4.25 #232 [ 526.140397] Hardware name: Qualcomm Technologies, Inc. SC7180 IDP (DT) [ 526.147113] Call trace: [ 526.149653] dump_backtrace+0x0/0x188 [ 526.153431] show_stack+0x20/0x2c [ 526.156852] dump_stack+0xdc/0x144 [ 526.160370] print_address_description+0x3c/0x494 [ 526.165211] __kasan_report+0x144/0x168 [ 526.169170] kasan_report+0x10/0x18 [ 526.172769] check_memory_region+0x1a4/0x1b4 [ 526.177164] __kasan_check_read+0x18/0x24 [ 526.181292] funnel_enable+0x54/0x1b0 [ 526.185072] coresight_enable_path+0x104/0x198 [ 526.189649] coresight_enable+0x118/0x26c [ 526.193778] enable_source_store+0x64/0xa8 [ 526.198007] dev_attr_store+0x40/0x58 [ 526.201788] sysfs_kf_write+0x4c/0x64 [ 526.205567] kernfs_fop_write+0x16c/0x210 [ 526.209700] __vfs_write+0x54/0x1a8 [ 526.213297] vfs_write+0xe4/0x1a4 [ 526.216714] ksys_write+0x84/0xec [ 526.220131] __arm64_sys_write+0x20/0x2c [ 526.224179] el0_svc_common+0xa8/0x160 [ 526.228040] el0_svc_compat_handler+0x2c/0x38 [ 526.232533] el0_svc_compat+0x8/0x10 [ 526.236225] [ 526.237782] Allocated by task 280: [ 526.241298] __kasan_kmalloc+0xf0/0x1ac [ 526.245249] kasan_kmalloc+0xc/0x14 [ 526.248849] __kmalloc+0x28c/0x3b4 [ 526.252361] coresight_register+0x88/0x250 [ 526.256587] funnel_probe+0x15c/0x228 [ 526.260365] dynamic_funnel_probe+0x20/0x2c [ 526.264679] amba_probe+0xbc/0x158 [ 526.268193] really_probe+0x144/0x408 [ 526.271970] driver_probe_device+0x70/0x140 [ 526.276282] __device_attach_driver+0x9c/0x110 [ 526.280861] bus_for_each_drv+0x90/0xd8 [ 526.284822] __device_attach+0xb4/0x164 [ 526.288772] device_initial_probe+0x20/0x2c [ 526.293081] bus_probe_device+0x34/0x94 [ 526.297030] deferred_probe_work_func+0xa4/0x100 [ 526.301794] process_one_work+0x33c/0x640 [ 526.305922] worker_thread+0x2a0/0x470 [ 526.309786] kthread+0x128/0x138 [ 526.313119] ret_from_fork+0x10/0x18 [ 526.316810] [ 526.318364] Freed by task 0: [ 526.321344] (stack is not available) [ 526.325024] [ 526.326580] The buggy address belongs to the object at ffffff8135f95480 [ 526.326580] which belongs to the cache kmalloc-128 of size 128 [ 526.339439] The buggy address is located 28 bytes inside of [ 526.339439] 128-byte region [ffffff8135f95480, ffffff8135f95500) [ 526.351399] The buggy address belongs to the page: [ 526.356342] page:ffffffff04b7e500 refcount:1 mapcount:0 mapping:ffffff814b00c380 index:0x0 compound_mapcount: 0 [ 526.366711] flags: 0x4000000000010200(slab|head) [ 526.371475] raw: 4000000000010200 ffffffff05034008 ffffffff0501eb08 ffffff814b00c380 [ 526.379435] raw: 0000000000000000 0000000000190019 00000001ffffffff 0000000000000000 [ 526.387393] page dumped because: kasan: bad access detected [ 526.393128] [ 526.394681] Memory state around the buggy address: [ 526.399619] ffffff8135f95380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 526.407046] ffffff8135f95400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 526.414473] >ffffff8135f95480: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 526.421900] ^ [ 526.426029] ffffff8135f95500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 526.433456] ffffff8135f95580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 526.440883] ================================================================== Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-04-07 13:56 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-05 10:28 [RFC PATCH] coresight: dynamic-replicator: Fix handling of multiple connections Sai Prakash Ranjan 2020-04-05 10:28 ` Sai Prakash Ranjan 2020-04-06 10:55 ` Mike Leach 2020-04-06 10:55 ` Mike Leach 2020-04-07 9:46 ` Sai Prakash Ranjan 2020-04-07 9:46 ` Sai Prakash Ranjan 2020-04-07 10:24 ` Suzuki K Poulose 2020-04-07 10:24 ` Suzuki K Poulose 2020-04-07 11:29 ` Sai Prakash Ranjan 2020-04-07 11:29 ` Sai Prakash Ranjan 2020-04-07 13:08 ` Suzuki K Poulose 2020-04-07 13:08 ` Suzuki K Poulose 2020-04-07 13:56 ` Sai Prakash Ranjan [this message] 2020-04-07 13:56 ` Sai Prakash Ranjan 2020-04-07 14:53 ` Suzuki K Poulose 2020-04-07 14:53 ` Suzuki K Poulose 2020-04-07 15:18 ` Sai Prakash Ranjan 2020-04-07 15:18 ` Sai Prakash Ranjan 2020-04-08 22:43 ` Suzuki K Poulose 2020-04-08 22:43 ` Suzuki K Poulose 2020-04-09 7:16 ` Stephen Boyd 2020-04-09 7:16 ` Stephen Boyd 2020-04-09 7:51 ` Sai Prakash Ranjan 2020-04-09 7:51 ` Sai Prakash Ranjan 2020-04-09 9:17 ` Suzuki K Poulose 2020-04-09 9:17 ` Suzuki K Poulose 2020-04-09 9:34 ` Sai Prakash Ranjan 2020-04-09 9:34 ` Sai Prakash Ranjan 2020-04-23 12:21 ` Sai Prakash Ranjan 2020-04-23 12:21 ` Sai Prakash Ranjan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bd05b31c2391edfff5044f22f2f83edf@codeaurora.org \ --to=saiprakash.ranjan@codeaurora.org \ --cc=alexander.shishkin@linux.intel.com \ --cc=leo.yan@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mathieu.poirier@linaro.org \ --cc=mike.leach@linaro.org \ --cc=suzuki.poulose@arm.com \ --cc=swboyd@chromium.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.