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

[Suzuki K Poulose]

On 04/07/2020 02:56 PM, Sai Prakash Ranjan wrote:
> 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

I am not sure how you have added the debugs, but it looks like the
drivers set 0xff for both the port filters on a successful probe.

> > 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.

Does your funnel have sparse input described ? I think we have an
issue with the "refcnt" tracking for funnels (especially). When we
have a sparse input ports described (ie. if only input ports 0, 3,
5 are described to protect the secure side connections), we could
end up accessing beyond the memory allocated for csdev->refcnts.
i.e, csdev->pdata->nr_inport = 3, and we could access csdev->refcnts[5],
while sizeof(csdev->refcnts) = sizeof(atomic_t) * 3.

I will send a patch.


> [Â 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

Suzuki