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

[Jie Gan]

On 4/15/2026 12:50 AM, Yeoreum Yun wrote:
> Hi,
>
> > On Mon, Apr 13, 2026 at 03:19:56PM +0100, Yeoreum Yun wrote:
> > > If etm4_enable_sysfs() fails in cscfg_csdev_enable_active_config(),
> > > the trace ID may be leaked because it is not released.
> > >
> > > To address this, call etm4_release_trace_id() when etm4_enable_sysfs()
> > > fails in cscfg_csdev_enable_active_config().
> > >
> > > Signed-off-by: Yeoreum Yun <yeoreum.yun@xxxxxxx>
> > > ---
> > >   drivers/hwtracing/coresight/coresight-etm4x-core.c | 4 +++-
> > >   1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > > index 8ebfd3924143..1bc9f13e33f7 100644
> > > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > > @@ -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);
> >
> > I am not familiar with the trace ID, seems to me, it just allocate a ID
> > for each tracer from the ID map and then always use this cached ID for
> > the tracers.
> >
> > 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 ?
>
> Agree. Practically, this is not a big issue and I don't think
> because of this new id couldn't be allocated in 128
> although the one id is occupied by cpu while source is disabled.
>
> However, in theory, this could lead to an ID leak,
> so it would be better to release it in error cases.

Actually, the 128 Trace ID is not enough for allocating. That's why the 
TPDM devices share the trace ID of the connected TPDA devices.

For the QCOM platform, we may got plenty of ETM devices (SoC with more 
than 20 Cores), lots of TPDM devices for each subsystem(CDSP, ADSP, GPU, 
GCC, MODEM, etc ...), and lots of dummy sources...

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,
Jie

> [...]
>
> --
> Sincerely,
> Yeoreum Yun