[PATCH v4 3/9] coresight: etm4x: fix leaked trace id
Leo Yan
leo.yan at arm.com
Wed Apr 15 01:32:24 PDT 2026
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!
More information about the linux-arm-kernel
mailing list