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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 7 Apr 2020 11:24:55 +0100
From:   Suzuki K Poulose <suzuki.poulose@....com>
To:     saiprakash.ranjan@...eaurora.org, mike.leach@...aro.org
Cc:     mathieu.poirier@...aro.org, leo.yan@...aro.org,
        alexander.shishkin@...ux.intel.com, swboyd@...omium.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org
Subject: Re: [RFC PATCH] coresight: dynamic-replicator: Fix handling of
 multiple connections

On 04/07/2020 10:46 AM, Sai Prakash Ranjan wrote:
> Hi Mike,
> 
> Thanks for taking a look.
> 
> On 2020-04-06 16:25, Mike Leach wrote:
>> Hi,
>>
>> The programmable replicator hardware by design enables trace through
>> both ports on reset. (see 1, section 4.4, 9.11)  The replicator driver
>> overrides this functionality to disable output, until the Coresight
>> infrastructure chooses a path from source to sink.
>> Now given that the hardware design is such that we must be able to
>> allow trace to be sent to both ports, a generic patch to prevent this
>> does not seem appropriate here.
>>
>> I think this needs further investigation - to determine why this
>> appears to be failing in this particular instance.
>>
> 
> Yes, this probably needs further investigation, but CPU hardlock stack
> trace doesnt help much. I could always trigger this hard lockup without
> this patch on SC7180 SoC and this is only seen when ETR is used as the 
> sink.
> 
> The only difference I could see between non working case (on SC7180 [1]) 
> and
> the working case (on SDM845 [2]) is the path from source to sink.


> 
> SC7180 source to sink path(Not working):
> ----------------------------------------
> 
>        etm0_out
>       |
>    apss_funnel_in0
>           |
>   apss_merge_funnel_in
>           |
>       funnel1_in4
>       |
>    merge_funnel_in1
>       |
>     swao_funnel_in
>           |
>         etf_in
>       |
>   swao_replicator_in
>           |
>    replicator_in
>       |
>         etr_in


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 ?)

After boot, what do the idfilter registers read for both the replicators ?


I believe we need to properly assign the TRACE_IDs for tracing sessions,
(rather than static ids) in a way such that we could filter them and use
the multiple sinks in parallel for separate trace sessions and this is
not simple (involves kernel driver changes and the perf tool to be able
to decode the trace id changes too).


So for the moment, we need to :

1) Disallow turning the replicator ON, when it is already turned ON
2) Do what your patch does. i.e, disable the other end while one end
    is turned on.

Thoughts ?

Kind regards
Suzuki