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

[Yeoreum Yun <yeoreum.yun@arm.com>]

Hi Leo,
> On Wed, Apr 15, 2026 at 09:21:21AM +0800, Jie Gan wrote:
>
> [...]
>
> > > > > @@ -918,8 +918,10 @@ static int etm4_enable_sysfs(struct coresight_device *csdev, struct coresight_pa
> > > > >   	cscfg_config_sysfs_get_active_cfg(&cfg_hash, &preset);
> > > > >   	if (cfg_hash) {
> > > > >   		ret = cscfg_csdev_enable_active_config(csdev, cfg_hash, preset);
> > > > > -		if (ret)
> > > > > +		if (ret) {
> > > > > +			etm4_release_trace_id(drvdata);
> > > >
> > > > If so, even an ID is reserved for failures, and the ID map is big enough
> > > > for each CPU, we don't need to worry memory leak or ID used out issue ?
> > >
> > > However, in theory, this could lead to an ID leak,
> > > so it would be better to release it in error cases.
> >
> > 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.


--
Sincerely,
Yeoreum Yun