Re: [RFC PATCH] coresight: dynamic-replicator: Fix handling of multiple connections

[Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>]

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