From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 892853CFF7E for ; Wed, 20 May 2026 10:13:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779272006; cv=none; b=FLa/VcFO80iYjGzJziWWUx0CwqG4RBJ8lNqsWJ0ikhqmznMndto61cG7B+HctG2YUVCesIbIBwx69ujIXDsP/pkr9kZaMsD8JMIsBP0TOJNbxWNjUIs6Ivq2RuFGUBOxXLhqEZR3c0Ls2bsJOkJW2B3P5id9fUsfxkwc5Rh+Nl4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779272006; c=relaxed/simple; bh=d7yX4maO4geYu1+xuLlJm2RqZMxDBm/WOj3QKECyq7M=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=pivQE6mblvqBFa8tAsjoScGcfMyBGAy9xdCkdcTps44UZ3eIyNqpOEo78p29p0MEA2yt9ZjIpTm6zJWnShZZIbE49fJLKiPbqDXS4CwN89baJbaBlnuKoXOfp+xisf/LacD2YC+TUjwIF1wOoGzeuG30AlhikH1gjo5atHxBaUM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=TaTOPc9O; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=KVQxJuyX; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="TaTOPc9O"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="KVQxJuyX" Received: from pps.filterd (m0279864.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 64K77XGI1953961 for ; Wed, 20 May 2026 10:13:24 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= Y6WtI20SOErt1sjmYgu/syjd2xP4m+G1yTbwc4/ASSY=; b=TaTOPc9O6oQGrnGP Cx8o8usfGK4YXWUv3vb+YrOcbNKFLMaVzqQ7m6Nghdb5lT/oNAFTddvy0hD/Yxe4 0uGHHeV9/JZvzMRk8wqhAfvaSkaviIJezUp2Yz2+EsUEHVPv53Tq3pzXiJJwkGSs ha76AKW5gjZC+HgZW99BvQZWnqSHaQ0mqp8ky9psRsWH0l1Je/f4ZjAubmj/+kUa Vv/XmiWJ7bmphU0RDGP77I5TZ1oHOz1f+yJmty/FJBTo5exhuVejQWkuinsI6+9Q ATszw5lZA+f3AkHRSIjcmXo2kgQCjd1y1FpTaMuYbapEheCUA6aiTwC3cmZp84YQ he1Oaw== Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4e8t3xv89x-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 20 May 2026 10:13:23 +0000 (GMT) Received: by mail-pj1-f71.google.com with SMTP id 98e67ed59e1d1-3663d5e9b9bso4664162a91.1 for ; Wed, 20 May 2026 03:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1779272003; x=1779876803; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Y6WtI20SOErt1sjmYgu/syjd2xP4m+G1yTbwc4/ASSY=; b=KVQxJuyXRHfbe74DitkOzwJ2X+VNq3iUe41KDc8j5pEU2VxWDJ90DO9Gc8ivgnrPr0 DGJznbMGt/5Kalm/a7qx5KNR0uDqX/VH08xd80p84Vz5tKSpCtRsd9kgj6MRG5OqvTHE GKzfeDKp6+7LhcgUv1jlAwWoRkcdQ24L6RjO/y6ym40nOKYAwZPgLY6sahhVshjlfYCR sJuTQDy3X+ZPyK5sSL4cONi887cT/wo1q+auxWyEco5N1mNCA1tiRzMo+6HHXmRPn9/i x38LsMiiyNJ+PNAiAegPJVB1yyIDGP4sxBi1CzZM157kIlYEECpFEFhBzeb5iOcipz+c FN5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779272003; x=1779876803; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Y6WtI20SOErt1sjmYgu/syjd2xP4m+G1yTbwc4/ASSY=; b=Blj+GhIchDC8GNhQCMUbdRfovAOUShTUyB/05JhfGNiWawVB9jokQbvpkf5JuCGy/9 AvVn5w7R70YCr3wH3KeHRwVsew+kbw7EwjbArfXZKMvoKa3fGR3GRSbcSWCPVwlpyoIy /vC3C+4wQADVtKI/acKr3D+77KsGKxMzN9rim5aKtK3Xi4kd48jYSzwjIPof4X1q4GmQ mwOzwK1OulZpkapD+UyTUK/Q8IMrVwPrhBX3kB/7nlOWPPmcVVdviqL5OXVM6UjboZ1M fdfPXWansPurOx7mgWW9fdSdilVfJCmmF4aYiMX6R+z27ONwkI7D4LbqQbXRiWQU9igB QWVg== X-Forwarded-Encrypted: i=1; AFNElJ+GRRuKD6s3k9BHv68ywgC6mAK/ZM9AP9DlYVj4Nkglosb/5TQLxXW6mUueCwKVp4ygrb83C7i637sK3O4=@vger.kernel.org X-Gm-Message-State: AOJu0Yw0zH7671+tlkzsReFXSbwvO+ObHAvz22LDnywmAW9esU4cNF86 ERci+FoXNUDeEsPtqBMgrGKY1LQEsALJqJ5pAJgWml12njTpiJNR/4bRdcFPHS/T2KyHCSCR+Yl 3JTA2eUUrFrVw7BSRP03Ny8ys+b8whK04hz6F3Yvj1w0quiU/uRpzicH01Z8oLy8vnyI= X-Gm-Gg: Acq92OGrh0iE+5Fi2vkMzLaRoaMEuCtVt7Zar/oxg8lWw9GBsqawVYNEDDBkM4fJGVr EUFYlwxMvjr8sZRX9bu+a9i5zVyFvDqIp9NX4hxmdxM3QUn4Anf6YO3+T9Fpbsdql/AOBKpw7OC k8QVeZSGfJyygleamZX1yL6Vdi3N5ij8Q6nOjKOfkXA0oL5BfkAFJargmVZfSEwAa3UeltuaaMJ oSOfmMbqirYBUtqoipK2RbsfZ5Afri5N4BBfEVgxWAg75hvB7ck/+e1gqTXb0oKR5gtZs64KZ5S hajrZQL0kkkTx2akOi3ekYoCsv1hjmBW1gcGkIQngZPbA/YYX/zXNPVmlPXKfp4mBKKQsvHzLKL HRvHr9XG5eH9ufeWH37ArYNPoSQfVh0gp0Nyldwmj+ErnxLBkeLZXDf74bK3FfUolYl/1D/+Lan FRwnSwMrFg8BQuNaxWXXc1jA== X-Received: by 2002:a17:90b:58e4:b0:366:755:6fee with SMTP id 98e67ed59e1d1-369519ea265mr21405565a91.12.1779272003025; Wed, 20 May 2026 03:13:23 -0700 (PDT) X-Received: by 2002:a17:90b:58e4:b0:366:755:6fee with SMTP id 98e67ed59e1d1-369519ea265mr21405531a91.12.1779272002567; Wed, 20 May 2026 03:13:22 -0700 (PDT) Received: from [10.133.33.129] (tpe-colo-wan-fw-bordernet.qualcomm.com. [103.229.16.4]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-369c5f0eb2bsm9113668a91.7.2026.05.20.03.13.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 May 2026 03:13:22 -0700 (PDT) Message-ID: Date: Wed, 20 May 2026 18:13:12 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] coresight: fix resource leaks on path build failure To: Mike Leach , James Clark Cc: "coresight@lists.linaro.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Suzuki Poulose , Leo Yan , Alexander Shishkin , Mathieu Poirier , Tingwei Zhang , Greg Kroah-Hartman , nd References: <20260513-fix-memory-leak-issue-v1-1-49822d7bc7d4@oss.qualcomm.com> <5b3785a1-0f53-4b61-bc18-880091c2ce12@oss.qualcomm.com> Content-Language: en-US From: Jie Gan In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authority-Analysis: v=2.4 cv=WaY8rUhX c=1 sm=1 tr=0 ts=6a0d8943 cx=c_pps a=UNFcQwm+pnOIJct1K4W+Mw==:117 a=nuhDOHQX5FNHPW3J6Bj6AA==:17 a=IkcTkHD0fZMA:10 a=NGcC8JguVDcA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=DJpcGTmdVt4CTyJn9g5Z:22 a=c92rfblmAAAA:8 a=KKAkSRfTAAAA:8 a=EUspDBNiAAAA:8 a=JfrnYn6hAAAA:8 a=VwQbUJbxAAAA:8 a=7CQSdrXTAAAA:8 a=QyXUC8HyAAAA:8 a=ag1SF4gXAAAA:8 a=BYRlHehqVJN5VeUu3RcA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=uKXjsCUrEbL0IQVhDsJ9:22 a=GvGzcOZaWPEFPQC_NcjD:22 a=cvBusfyB2V15izCimMoJ:22 a=1CNFftbPRP8L7MoqJWF3:22 a=a-qgeE7W1pNrGK8U0ZQC:22 a=Yupwre4RP9_Eg_Bd0iYG:22 X-Proofpoint-GUID: oCjQ6s4CZ3-CvNiuU92ESLoCHdGcjr7p X-Proofpoint-ORIG-GUID: oCjQ6s4CZ3-CvNiuU92ESLoCHdGcjr7p X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNTIwMDA5OCBTYWx0ZWRfXzAlV7HaaaPve VfUhWbPIbB1r4yBeo4VGWVQ3BGopzVqF/mIVFnWdWe2KIXyUbV4q2DJIfbXbGPXwVdW1cmIOE// bw2KX9Gqr+4IdVhSIAz9B7jF4WJpuIQULXV/kpwyiZpgFBvHmm+72RMIg/GNOmJ2UMzYFbR9fiW tWjfkLY2vgqpHlz63b3+/ISPrUEirvYI3Jr33J8Lvo/gqH/Vb6GwlvEAhlvb7EZtT2SClm2iJ3u d0aUd+QxzZP+jNLensFm1glYb9uSwhhoPsI2mADco7mp24eZmRr0iGYPnddJJA7xz163+U7K7dH On62FKmxEPARCLEoaWxGY3YDNuF4Nixjh/7iEm8MxB741efS47cDqTf+QRT9npuYxU/eIJ33T/w p76YA/yofwKZFURz8scQVcId+izf5G/Bx07On6eyMzI5FzcNC+B86RC4+VQXAUtTGOm0TWUFrHi bUpB0wOuAZXi+4TAsMw== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-05-20_02,2026-05-18_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 priorityscore=1501 clxscore=1015 impostorscore=0 spamscore=0 suspectscore=0 phishscore=0 bulkscore=0 lowpriorityscore=0 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2605130000 definitions=main-2605200098 On 5/20/2026 5:27 PM, Mike Leach wrote: > > >> -----Original Message----- >> From: James Clark >> Sent: Wednesday, May 20, 2026 9:38 AM >> To: Jie Gan >> Cc: coresight@lists.linaro.org; linux-arm-kernel@lists.infradead.org; linux- >> kernel@vger.kernel.org; Suzuki Poulose ; Mike >> Leach ; Leo Yan ; Alexander >> Shishkin ; Mathieu Poirier >> ; Tingwei Zhang >> ; Greg Kroah-Hartman >> >> Subject: Re: [PATCH] coresight: fix resource leaks on path build failure >> >> >> >> On 20/05/2026 2:55 am, Jie Gan wrote: >>> >>> >>> On 5/19/2026 9:57 PM, James Clark wrote: >>>> >>>> >>>> On 13/05/2026 2:32 am, Jie Gan wrote: >>>>> Two related leaks when _coresight_build_path() encounters an error after >>>>> coresight_grab_device() has already incremented the pm_runtime, >> module, >>>>> and device references for a node: >>>>> >>>>> 1. In _coresight_build_path(), if kzalloc_obj() for the path node fails >>>>>     after coresight_grab_device() succeeds, coresight_drop_device() was >>>>>     never called, permanently leaking all three references. >>>>> >>>>> 2. In coresight_build_path(), on failure the partial path was freed with >>>>>     kfree(path) instead of coresight_release_path(path).  kfree() only >>>>>     frees the coresight_path struct itself; it does not iterate >>>>> path_list >>>>>     to call coresight_drop_device() and kfree() for each coresight_node >>>>>     already added by deeper recursive calls, leaking both the >>>>> pm_runtime, >>>>>     module, and device references and the node memory for every element >>>>>     on the partial path. >>>>> >>>>> Fix both by adding coresight_drop_device() in the OOM unwind of >>>>> _coresight_build_path(), and replacing kfree(path) with >>>>> coresight_release_path(path) in coresight_build_path(). >>>>> >>>>> Fixes: 32b0707a4182 ("coresight: Add try_get_module() in >>>>> coresight_grab_device()") >>>>> Fixes: b3e94405941e ("coresight: associating path with session rather >>>>> than tracer") >>>>> Signed-off-by: Jie Gan >>>>> --- >>>>>   drivers/hwtracing/coresight/coresight-core.c | 6 ++++-- >>>>>   1 file changed, 4 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/ >>>>> hwtracing/coresight/coresight-core.c >>>>> index 46f247f73cf6..c1354ea8e11d 100644 >>>>> --- a/drivers/hwtracing/coresight/coresight-core.c >>>>> +++ b/drivers/hwtracing/coresight/coresight-core.c >>>>> @@ -825,8 +825,10 @@ static int _coresight_build_path(struct >>>>> coresight_device *csdev, >>>>>           return ret; >>>>>       node = kzalloc_obj(struct coresight_node); >>>>> -    if (!node) >>>>> +    if (!node) { >>>>> +        coresight_drop_device(csdev); >>>>>           return -ENOMEM; >>>>> +    } >>>>>       node->csdev = csdev; >>>>>       list_add(&node->link, &path->path_list); >>>>> @@ -851,7 +853,7 @@ struct coresight_path >>>>> *coresight_build_path(struct coresight_device *source, >>>>>       rc = _coresight_build_path(source, source, sink, path); >>>>>       if (rc) { >>>>> -        kfree(path); >>>>> +        coresight_release_path(path); >>>>>           return ERR_PTR(rc); >>>>>       } >>>>> >>>>> --- >>>>> base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83 >>>>> change-id: 20260513-fix-memory-leak-issue-034b4a45265e >>>>> >>>>> Best regards, >>>> >>>> Looks good to me, but sashiko is complaining: https://sashiko.dev/#/ >>>> patchset/20260513-fix-memory-leak-issue- >>>> v1-1-49822d7bc7d4%40oss.qualcomm.com >>>> >>>> I'm trying to understand why it's saying that, but I think the >>>> scenario is that if there are multiple correct paths to a sink, when >>>> one path partially fails and a second path succeeds you could get a >>>> path_list with some garbage entries in it. >>> >>> I think the coresight_release_path is added to address this situation. >>> We suffered the path partially failure, and we need release all nodes >>> already added to the path. >>> >> >> It wouldn't call coresight_release_path() in this case though. If one >> path ends up building to success but a parallel path partially failed >> then _coresight_build_path() still returns success. During the search it >> would have still added the nodes from the partially failed path to the >> path_list. This is only an issue if there are multiple correct paths. >> The point here is there are multiple routes from the same source device to the same sink device, am right? I have no experience on this scenario. So with the scenario, the build_path may succeeded in one route and failed in another route, but finally, the _coresight_build_path still returns success, is that correct? >>>> >>>> That's kind of a different and existing issue to the one you've fixed, >>>> and assumes that multiple paths to one sink are possible, which I'm >>>> not sure is supported? >>> >>> Each path is unique. We only deal with the issue path for balancing the >>> reference count. >>> >>> Thanks, >>> Jie >>> >> >> I'm not exactly sure what you mean by unique, but the same source and >> sink could potentially be connected through two different sets of links. >> > > Multiple paths between a source and sink are not permitted under the CoreSight spec. > As Mike mentioned, my understanding is that a source device is only allowed to be added to one valid path—this is what I mean by “unique.” Thanks, Jie > If such a system was to be built - then a fix would need to be in the declaration of connections - e.g. miss one path out in the device tree for example. Not up to the Coresight drivers to handle out of specification hardware. > > Mike > > >>>> >>>> It might be as easy as breaking the loop early for any return value >>>> other than -ENODEV, but I'll leave it to you to decide whether to do >>>> that here or not. >>>> >>>> Reviewed-by: James Clark >>>> >>> >