From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E1369256C6D for ; Tue, 14 Apr 2026 16:32:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776184345; cv=none; b=htPRixwd+/Nk9K6DWse0nuOLE/9SJXYLeYO7EgXwicGgLuzNPmj3yV+jDf/Xxay/iFcYqHCHhknCYpDfjYiZvvrEqyFc4PCBsaBYiS1DEytpBixDfm1J/0/PDjk2w98mmV7SlxOdk3md/lClcQ9NBD3CqrnV3JwFoF7EeIzWgVE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776184345; c=relaxed/simple; bh=P55B9TXscDbVPBMMKx0AgxGjHZwwqjld9LQAZsfoyBY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZwL3Qof2bPRuUWI8vWc+6l7SqIB5OqstE+MuIaFe+BorR/rOw7rUf53OB805wC90In16IgdzkNgeWXQKv9kbDVhsZAgAX+MxJL+5+sAps2kbZ+OPHQUsZrem6eiMxJDx2EyGNH6D5JL2FTfKJRcdf5K7nkSEsCCo2ihPqikB+0k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=ANAWK0gO; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="ANAWK0gO" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id AA5E7337D; Tue, 14 Apr 2026 09:32:17 -0700 (PDT) Received: from localhost (e132581.arm.com [10.1.196.87]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F2DC43F641; Tue, 14 Apr 2026 09:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1776184343; bh=P55B9TXscDbVPBMMKx0AgxGjHZwwqjld9LQAZsfoyBY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ANAWK0gOifUE0it1gUj/LI3u2kAkBzDhVDGBIhFo8SowLqqwfGXZlDHaFbj8NpY1D hFSg6BWJ724D4/rI8MDY1oQqlgOyOlZg8qarIdr0ymgjbOLvBKORRzkLYXs5u45qDD Tg3s2Mn1k3YhogmTOS12aAk+uduU6h5APN8AxOqA= Date: Tue, 14 Apr 2026 17:32:21 +0100 From: Leo Yan To: Yeoreum Yun Cc: coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, suzuki.poulose@arm.com, mike.leach@arm.com, james.clark@linaro.org, alexander.shishkin@linux.intel.com, jie.gan@oss.qualcomm.com Subject: Re: [PATCH v4 3/9] coresight: etm4x: fix leaked trace id Message-ID: <20260414163221.GG356832@e132581.arm.com> References: <20260413142003.3549310-1-yeoreum.yun@arm.com> <20260413142003.3549310-4-yeoreum.yun@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260413142003.3549310-4-yeoreum.yun@arm.com> 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 > --- > 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 ? Thanks, Leo > return ret; > + } > } > > raw_spin_lock(&drvdata->spinlock); > -- > LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7} >