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] [day] [month] [year] [list]
Message-ID: <5c0827ce-cf25-43d0-a160-5f99e82f582c@quicinc.com>
Date: Thu, 16 Jan 2025 11:01:03 +0800
From: Jie Gan <quic_jiegan@...cinc.com>
To: James Clark <james.clark@...aro.org>
CC: Jinlong Mao <quic_jinlmao@...cinc.com>, <coresight@...ts.linaro.org>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        <devicetree@...r.kernel.org>,
        Tingwei Zhang <quic_tingweiz@...cinc.com>,
        <linux-arm-msm@...r.kernel.org>,
        <linux-stm32@...md-mailman.stormreply.com>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        Mike Leach
	<mike.leach@...aro.org>,
        Alexander Shishkin
	<alexander.shishkin@...ux.intel.com>,
        Maxime Coquelin
	<mcoquelin.stm32@...il.com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>
Subject: Re: [PATCH v8 2/5] Coresight: Add trace_id function to retrieving the
 trace ID



On 1/15/2025 8:29 PM, James Clark wrote:
> 
> 
> On 15/01/2025 1:44 am, Jie Gan wrote:
>>
>>
>> On 1/14/2025 6:07 PM, James Clark wrote:
>>>
>>>
>>> On 14/01/2025 2:51 am, Jie Gan wrote:
>>>>
>>>>
>>>> On 1/13/2025 8:02 PM, James Clark wrote:
>>>>>
>>>>>
>>>>> On 26/12/2024 1:10 am, Jie Gan wrote:
>>>>>> Add 'trace_id' function pointer in ops. It's responsible for
>>>>>> retrieving the device's trace ID.
>>>>>>
>>>>>> Add 'struct cs_sink_data' to store the data that is needed by
>>>>>> coresight_enable_path/coresight_disable_path. The structure
>>>>>> will be transmitted to the helper and sink device to enable
>>>>>> related funcationalities.
>>>>>>
>>>>>
>>>>> The new cs_sink_data struct is quite specific to this change. Can 
>>>>> we start passing the path around to enable/disable functions, that 
>>>>> will allow devices to gather anything they want in the future. 
>>>>> Because we already have coresight_get_sink(path), 
>>>>> coresight_get_source(path) etc.
>>>>>
>>>>> And see below, but for this case we can also change the path struct 
>>>>> to contain the trace ID. Then all the new functions, allocations 
>>>>> and searches for the trace ID are unecessary. The CTCU will have 
>>>>> access to the path, and by the time its enable function is called 
>>>>> the trace ID is already assigned.
>>>>>
>>>>> It's also easier to understand at which point a trace ID is 
>>>>> allocated, rather than adding the trace_id() callbacks from 
>>>>> everywhere which could potentially either read or allocate. I 
>>>>> suppose that's "safer" because maybe it's not allocated, but I 
>>>>> can't see what case it would happen in reverse.
>>>>>
>>>> Thank you for comment. I will try this solution.
>>>> The biggest challenge for the patch is how to correctly read 
>>>> trace_id from source device and passthrough it to helper device as 
>>>> the source device always the last one to enable. I believe your 
>>>> proposed solution is better than mine and has minimal impact on the 
>>>> basic framework, but I think we still need read_trace in source_ops 
>>>> and link_ops. Then we can read the trace_id in coresight_build_path 
>>>> function and save it to the coresight_path to avoid redundant 
>>>> searching?
>>>>
>>>>
>>>>>> Signed-off-by: Jie Gan <quic_jiegan@...cinc.com>
>>>>>> ---
>>>>>>   drivers/hwtracing/coresight/coresight-core.c  | 59 +++++++++++++ 
>>>>>> + +----
>>>>>>   drivers/hwtracing/coresight/coresight-etb10.c |  3 +-
>>>>>>   .../hwtracing/coresight/coresight-etm-perf.c  | 37 ++++++++++--
>>>>>>   .../coresight/coresight-etm3x-core.c          | 30 ++++++++++
>>>>>>   .../coresight/coresight-etm4x-core.c          | 29 +++++++++
>>>>>>   drivers/hwtracing/coresight/coresight-priv.h  | 13 +++-
>>>>>>   drivers/hwtracing/coresight/coresight-stm.c   | 22 +++++++
>>>>>>   drivers/hwtracing/coresight/coresight-sysfs.c | 24 +++++++-
>>>>>>   .../hwtracing/coresight/coresight-tmc-etf.c   |  3 +-
>>>>>>   .../hwtracing/coresight/coresight-tmc-etr.c   |  6 +-
>>>>>>   drivers/hwtracing/coresight/coresight-tpda.c  | 20 +++++++
>>>>>>   drivers/hwtracing/coresight/coresight-trbe.c  |  4 +-
>>>>>>   drivers/hwtracing/coresight/ultrasoc-smb.c    |  3 +-
>>>>>>   include/linux/coresight.h                     |  6 ++
>>>>>>   14 files changed, 234 insertions(+), 25 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/ 
>>>>>> drivers/ hwtracing/coresight/coresight-core.c
>>>>>> index 0a9380350fb5..2e560b425fd4 100644
>>>>>> --- a/drivers/hwtracing/coresight/coresight-core.c
>>>>>> +++ b/drivers/hwtracing/coresight/coresight-core.c
>>>>>> @@ -23,6 +23,7 @@
>>>>>>   #include "coresight-etm-perf.h"
>>>>>>   #include "coresight-priv.h"
>>>>>>   #include "coresight-syscfg.h"
>>>>>> +#include "coresight-trace-id.h"
>>>>>>   /*
>>>>>>    * Mutex used to lock all sysfs enable and disable actions and 
>>>>>> loading and
>>>>>> @@ -331,12 +332,12 @@ static int coresight_enable_helper(struct 
>>>>>> coresight_device *csdev,
>>>>>>       return helper_ops(csdev)->enable(csdev, mode, data);
>>>>>>   }
>>>>>> -static void coresight_disable_helper(struct coresight_device *csdev)
>>>>>> +static void coresight_disable_helper(struct coresight_device 
>>>>>> *csdev, void *data)
>>>>>>   {
>>>>>> -    helper_ops(csdev)->disable(csdev, NULL);
>>>>>> +    helper_ops(csdev)->disable(csdev, data);
>>>>>>   }
>>>>>> -static void coresight_disable_helpers(struct coresight_device 
>>>>>> *csdev)
>>>>>> +static void coresight_disable_helpers(struct coresight_device 
>>>>>> *csdev, void *data)
>>>>>>   {
>>>>>>       int i;
>>>>>>       struct coresight_device *helper;
>>>>>> @@ -344,7 +345,7 @@ static void coresight_disable_helpers(struct 
>>>>>> coresight_device *csdev)
>>>>>>       for (i = 0; i < csdev->pdata->nr_outconns; ++i) {
>>>>>>           helper = csdev->pdata->out_conns[i]->dest_dev;
>>>>>>           if (helper && coresight_is_helper(helper))
>>>>>> -            coresight_disable_helper(helper);
>>>>>> +            coresight_disable_helper(helper, data);
>>>>>>       }
>>>>>>   }
>>>>>> @@ -361,7 +362,7 @@ static void coresight_disable_helpers(struct 
>>>>>> coresight_device *csdev)
>>>>>>   void coresight_disable_source(struct coresight_device *csdev, 
>>>>>> void *data)
>>>>>>   {
>>>>>>       source_ops(csdev)->disable(csdev, data);
>>>>>> -    coresight_disable_helpers(csdev);
>>>>>> +    coresight_disable_helpers(csdev, NULL);
>>>>>>   }
>>>>>>   EXPORT_SYMBOL_GPL(coresight_disable_source);
>>>>>> @@ -371,7 +372,8 @@ EXPORT_SYMBOL_GPL(coresight_disable_source);
>>>>>>    * disabled.
>>>>>>    */
>>>>>>   static void coresight_disable_path_from(struct list_head *path,
>>>>>> -                    struct coresight_node *nd)
>>>>>> +                    struct coresight_node *nd,
>>>>>> +                    void *sink_data)
>>>>>>   {
>>>>>>       u32 type;
>>>>>>       struct coresight_device *csdev, *parent, *child;
>>>>>> @@ -417,13 +419,13 @@ static void 
>>>>>> coresight_disable_path_from(struct list_head *path,
>>>>>>           }
>>>>>>           /* Disable all helpers adjacent along the path last */
>>>>>> -        coresight_disable_helpers(csdev);
>>>>>> +        coresight_disable_helpers(csdev, sink_data);
>>>>>>       }
>>>>>>   }
>>>>>> -void coresight_disable_path(struct list_head *path)
>>>>>> +void coresight_disable_path(struct list_head *path, void *sink_data)
>>>>>>   {
>>>>>> -    coresight_disable_path_from(path, NULL);
>>>>>> +    coresight_disable_path_from(path, NULL, sink_data);
>>>>>>   }
>>>>>>   EXPORT_SYMBOL_GPL(coresight_disable_path);
>>>>>> @@ -505,10 +507,47 @@ int coresight_enable_path(struct list_head 
>>>>>> *path, enum cs_mode mode,
>>>>>>   out:
>>>>>>       return ret;
>>>>>>   err:
>>>>>> -    coresight_disable_path_from(path, nd);
>>>>>> +    coresight_disable_path_from(path, nd, sink_data);
>>>>>>       goto out;
>>>>>>   }
>>>>>> +int coresight_read_traceid(struct list_head *path, enum cs_mode 
>>>>>> mode,
>>>>>> +               struct coresight_trace_id_map *id_map)
>>>>>> +{
>>>>>> +    int trace_id, type;
>>>>>> +    struct coresight_device *csdev;
>>>>>> +    struct coresight_node *nd;
>>>>>> +
>>>>>> +    list_for_each_entry(nd, path, link) {
>>>>>
>>>>> What do you think about also changing the path to this:
>>>>>
>>>>>   struct coresight_path {
>>>>>     struct list_head *path,
>>>>>     u8 trace_id
>>>>>   };
>>>>>
>>>> That's better, I can simplify the coresight_read_traceid function 
>>>> without traverse the path.
>>>>
>>>> But we still need to check the type of the coresight device, because 
>>>> the TPDM does not have traceid and we use the trace_id from the TPDA 
>>>> device that the TPDM connected. That's why I added trace_id to 
>>>> link_ops.
>>>>
>>>
>>> But if any device that allocates a trace ID saves it into the path, 
>>> then as long as any other device that needs the ID is enabled after 
>>> that it just reads it from the path directly. Assuming we pass the 
>>> path to every enable and disable function.
>>>
>>> We wouldn't need coresight_read_traceid() if it always happens that 
>>> way around, which I think it currently does?
>>>
>> I got your point here. You are right. If we passed path to the helper 
>> device, just use coresight_get_source to obtain the source device, 
>> then call the source_ops->trace_id to obtain the trace_id. So we 
>> definitely dont need a standalone function, coresight_read_traceid().
>>
>> Besides, I still need a function to retrive the trace_id of the TPDA 
>> device if the source device is TPDM, right?
>>
>>
>> Thanks,
>> Jie
>>
> 
> Yes, and that would require a search as the TPDA not always at one end 
> of the path like coresight_get_source() and coresight_get_sink(). Which 
> is why I was thinking it might be good to save the trace ID in the path 
> struct to avoid it.
> 
As you proposed, I created coresight_path structure as below:
struct coresight_path {
	struct perf_output_handle       *handle;
	struct list_head                *path;
	u8				trace_id;
};

In coresight_enable_path, I modified the parameters that transmitted to 
helper device:
struct coresight_path *cs_path;

coresight_enable_helpers(csdev, mode, sink_data) ->
coresight_enable_helpers(csdev, mode, cs_path)

The cs_path will be constructed and initialized in coresight_build_path 
function.

For perf mode, the trace_id is collected within etm_setup_aux and stored 
in cs_path->trace_id to avoid extra cost of retrieving the trace_id;

For sysfs mode, I let the CTCU device to retrieving the trace_id with 
path. The TPDA device is located close to the TPDM, making the cost of 
searching for the TPDA device acceptable.

The cs_path will be stored in the same manner as the previous path.

How do you think about this solution?

Thanks,
Jie

[...]


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ