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 85358264614 for ; Thu, 16 Apr 2026 16:55:44 +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=1776358545; cv=none; b=PtY/MUDFX0+chrs022aUOg3WYW7frgM4f8u9KFknvTT7LOy1t3LYLlu7twKyapXAzN9KEr6SgDCNY3vmsjkYj/pIXzfnfveRvtQp0KPfirvi97L0O7mxzs5OwHwppQSlV2Kv9gq2O8uXLSBI5NnkovZDCNENMUIbL3vRfrofKuM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776358545; c=relaxed/simple; bh=/hViHlF5ifQBVvKwNQRn66elzsDuXATBenpBXrMug7Y=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MCfmWwfO48J0uoyX5aAFc+7lPVv6nZIzuy1InufQmEw9S95u43Fk0N8kFXbrub9LS6EzuhDqUDXdxR1P+WsseywXTykIqM3bd9jNiS/u4zIYMezZUc4/69fEPJ/0sT3G48/rzRu+jC/OCzMfi8931OXHBU6PAaLK5oWF4Tgr5qI= 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=PpYSzGdW; 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="PpYSzGdW" 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 4434724C0; Thu, 16 Apr 2026 09:55:38 -0700 (PDT) Received: from localhost (e132581.arm.com [10.1.196.87]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 794013F7D8; Thu, 16 Apr 2026 09:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1776358543; bh=/hViHlF5ifQBVvKwNQRn66elzsDuXATBenpBXrMug7Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PpYSzGdWtiIGuSx503F6Zo22Vb9nAWEtPUGJjRP/JYajnWV6jp/UPXgpctrxCkO86 XZtTL5G8T/f0JWC0Rj+3IScB8AEJSxXorlPxC+W5SoFYYc91jVCXNwNEBGoFz146UH AFbdDHoK83Ii3VH8OwQv+HSKA+sRKQLCfhOWx0Xo= Date: Thu, 16 Apr 2026 17:55:41 +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 v5 06/12] coresight: etm4x: fix leaked trace id Message-ID: <20260416165541.GN356832@e132581.arm.com> References: <20260415165528.3369607-1-yeoreum.yun@arm.com> <20260415165528.3369607-7-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: <20260415165528.3369607-7-yeoreum.yun@arm.com> On Wed, Apr 15, 2026 at 05:55:22PM +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(). > > Reviewed-by: Jie Gan > 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 f55338a4989d..b199aebbdb60 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c > @@ -920,8 +920,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); > return ret; > + } LGTM: Reviewed-by: Leo Yan Just recording a bit thoughts. As Suzuki mentioned, it would be better to allocate trace IDs within a session. We might consider maintaining the trace ID map in the sink driver data, since the sink driver is unique within a session so it is a central place to allocate trace ID. We should use paired way for allocation and release. For example: coresight_enable_sysfs() { ... coresight_path_assign_trace_id(path); failed: coresight_path_unassign_trace_id(path); } coresight_disable_sysfs() { coresight_path_unassign_trace_id(path); } But this requires broader refactoring. E.g., the STM driver currently allocates system trace IDs statically during probe, we might need to consolidate for all modules to use dynamic allocation. Thanks, Leo