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

[Leo Yan <leo.yan@arm.com>]

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.

Thanks,
Leo