Re: [PATCH v4 3/9] coresight: etm4x: fix leaked trace id

[Suzuki K Poulose <suzuki.poulose@arm.com>]

On 15/04/2026 09:45, Jie Gan wrote:
> 
> 
> On 4/15/2026 4:32 PM, Leo Yan wrote:
>> On Wed, Apr 15, 2026 at 09:01:09AM +0100, Yeoreum Yun wrote:
>>
>> [...]
>>
>>>>> What I am thinking is as SoCs continue to grow more complex with an
>>>>> increasing number of subsystems, trace IDs may be exhausted in the 
>>>>> near
>>>>> future. (that's why we have dynamic trace ID allocation/release).
>>>>
>>>> Thanks for the input.
>>>>
>>>> I am wandering if we can use "dev->devt" as the trace ID.  A device's
>>>> major/minor number is unique in kernel and dev_t is defined as u32:
>>>>
>>>>    typedef u32 __kernel_dev_t;
>>>>
>>>> And we can consolidate this for both SYSFS and PERF modes.
>>>>
>>>
>>> When I see the CORESIGHT_TRACE_ID_MAX:
>>>
>>>   /* architecturally we have 128 IDs some of which are reserved */
>>>    #define CORESIGHT_TRACE_IDS_MAX 128
>>>
>>> I think this came from the hardware restriction for number of TRACE_IDs.
>>> In this case, clamping the device_id to trace_id seems more complex and
>>> reduce some performance perspective.
>>
>> Sigh, my stupid.  Please ignore my previous comment, let us first fix
>> ID leak issue.
>>
>> Given Jie's comment on the use-out issue, it is valid for me especially
>> if a system have many dummy tracers.  We can defer to refactor it
>> later (e.g., use separate ranges for hardware and dummy tracers).
>>
>> thanks for correction!
> 
> Just share some info:
> 
> With my memory, The ARM AMBA ATB Protocol Specification defined a 7-bit 
> width field for the trace ID, that's where the 128 comes from. (in each 
> frame, we also have 7-bit field for containing the trace ID)

That is true and some IDs in the range (0-128) are reserved. So we
actually have less than 128. We need the dynamic allocation, preferrably
isolated to a "pool" for the relevant session to make the full use of
the space.

Suzuki

> 
> Thanks,
> Jie
>