Message ID | 20231117173650.21161-1-johan+linaro@kernel.org |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9910:0:b0:403:3b70:6f57 with SMTP id i16csp698351vqn; Fri, 17 Nov 2023 09:38:55 -0800 (PST) X-Google-Smtp-Source: AGHT+IE9XAY9mLWA/0ihzJsYtJCoMv9CQrMoMe76W+lVBlpnzKXP44kfzlaqo21YzhF2rCNwW06F X-Received: by 2002:a05:6a20:e10d:b0:187:97fc:6c56 with SMTP id kr13-20020a056a20e10d00b0018797fc6c56mr9797232pzb.49.1700242735510; Fri, 17 Nov 2023 09:38:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700242735; cv=none; d=google.com; s=arc-20160816; b=nVCWQhnaXXHO7g+F14uP+Fw2Za/FKtR82I7WZeKn9+gyZ4bw+GlY0oVTaoTKioXHGW QTeDR7IKQ5IR6GHNAKyKVvtYaHfUFDDGBBjtqy0+nLlzXAH0VpszUyDAxyM8WKFBXtbl q9TVloMyt9aIn/7M2dylYWDio0A7YlbKjvMDJfGzG30gtxKXoc8pKulVZkMyDVWq6zvL Ps1A5ARZNC684Qej+HsCvRSrIz7oVRPn+tUFPngp+5U/kL6kIQfoDalN3PBdR1u0CmXh 2HJB7yV5BrLzzFQiZjrVy+USzJUVzZV0m9arn8lT3Jwhp+vufny/0gFl1ytU3V/R1j46 3pHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=+sO2ofpXTysHAooH+mMazS/VDIHQ2P72FiD3W6E9VlQ=; fh=5YLC7FhBjPlPuzyWSdvJbjRUzXTUgp22G+zSVnjVn/o=; b=I5FAy3YO0pfTHe0yPbnwtzGZj2OPUfPVnmfVtyANDVYLvQc45RxUfT6unZfQkX4Na4 4vkAPg18/bT6BfM56H/90zaQhVUUM0p72y2hF+AgVHxQeRExsJcKVRtmXGZqXKGS/lVp vyGJS/gF+Au0nv7VuxXe0LkW3cBWyRCHg7JCfUcDSe2j4Lx4RmmG3I60mbF9rM5T40na tJRjR7UGjIjP25Rwx1E61+hIyYKl1j86P5Kgynh9BxweHJ2H4dk1DdeKjjPkUIk2Iwcf zDF5B4jGdR7h8VaLHoUCYdCyxby+xNqIef6SAYAqOJGwFvUUhU3NGo3OFP46cy/inM4T YZAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=mtKlfPUJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id d15-20020a056a00244f00b0068fcf194dacsi2405136pfj.92.2023.11.17.09.38.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Nov 2023 09:38:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=mtKlfPUJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 46D2D8342FE0; Fri, 17 Nov 2023 09:38:53 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346178AbjKQRiN (ORCPT <rfc822;jaysivo@gmail.com> + 30 others); Fri, 17 Nov 2023 12:38:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58152 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346173AbjKQRiM (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 17 Nov 2023 12:38:12 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C343E10E5 for <linux-kernel@vger.kernel.org>; Fri, 17 Nov 2023 09:38:09 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 66A95C433C9; Fri, 17 Nov 2023 17:38:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1700242689; bh=EUDBFroF5TjmYX0MrqbQ4lm7E/YuA+W3eE3VkPGKcm4=; h=From:To:Cc:Subject:Date:From; b=mtKlfPUJjJanONH237bSO3hOyU3SFX6xd57lxI10FihF5J/Mibv8D4PbuIiO4F5iy d4WA6/sHLhtXtn85tmoz8qRflR9TgpG14tbbU/u2a+SMRM04OTf2y5kJnuo0mfTcaE gQEg3YiAE39DARcXgaIYF5Ia1GBGkJ168le7YTOy0vg6tGGvcbwVyn7HDnnam8h3LV zJcX6KP7XzZSux28CArPbMBqEOCUU/OawwwhIYsz5NMxZWpfI21s3i3LoJkBgHAJ2H AYbrHhzqOdeRqKQjNWy+AcyBPetP5rOABkVxIGI+Tc5v3faQwuhgO9stvbnF/Q9zUT 9E3RhmkCzm4fA== Received: from johan by xi.lan with local (Exim 4.96.2) (envelope-from <johan+linaro@kernel.org>) id 1r42nF-0005Vo-0K; Fri, 17 Nov 2023 18:38:13 +0100 From: Johan Hovold <johan+linaro@kernel.org> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Thinh Nguyen <Thinh.Nguyen@synopsys.com>, Krishna Kurapati PSSNV <quic_kriskura@quicinc.com>, linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Johan Hovold <johan+linaro@kernel.org> Subject: [PATCH 0/3] USB: dwc3: qcom: fix resource leaks on probe deferral Date: Fri, 17 Nov 2023 18:36:47 +0100 Message-ID: <20231117173650.21161-1-johan+linaro@kernel.org> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Fri, 17 Nov 2023 09:38:53 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1782833688024321829 X-GMAIL-MSGID: 1782833726699125998 |
Series |
USB: dwc3: qcom: fix resource leaks on probe deferral
|
|
Message
Johan Hovold
Nov. 17, 2023, 5:36 p.m. UTC
When reviewing the recently submitted series which reworks the dwc3 qcom glue implementation [1], I noticed that the driver's tear down handling is currently broken, something which can lead to memory leaks and potentially use-after-free issues on probe deferral and on driver unbind. Let's get this sorted before reworking driver. Note that the last patch has only been compile tested as I don't have access to a sdm845 device. Johan [1] https://lore.kernel.org/lkml/20231016-dwc3-refactor-v1-0-ab4a84165470@quicinc.com/ Johan Hovold (3): USB: dwc3: qcom: fix resource leaks on probe deferral USB: dwc3: qcom: fix software node leak on probe errors USB: dwc3: qcom: fix ACPI platform device leak drivers/usb/dwc3/dwc3-qcom.c | 57 +++++++++++++++++++++++++++--------- 1 file changed, 43 insertions(+), 14 deletions(-)
Comments
On 17.11.2023 18:36, Johan Hovold wrote: > When reviewing the recently submitted series which reworks the dwc3 qcom > glue implementation [1], I noticed that the driver's tear down handling > is currently broken, something which can lead to memory leaks and > potentially use-after-free issues on probe deferral and on driver > unbind. > > Let's get this sorted before reworking driver. > > Note that the last patch has only been compile tested as I don't have > access to a sdm845 device. > > Johan I'll sound like a broken record, but: is there anyone in the world that is actively benefiting from this failed experiment of using the ACPI tables that were shipped with these SoCs? There are so so so many shortcomings associated with it due to how Windows drivers on these platforms know waaaay too much and largely use ACPI to "bind driver x" and I simply think it doesn't make sense to continue carrying this code forward given little use and no testing. Konrad
On Sat, Nov 18, 2023 at 12:47:30AM +0100, Konrad Dybcio wrote: > On 17.11.2023 18:36, Johan Hovold wrote: > > When reviewing the recently submitted series which reworks the dwc3 qcom > > glue implementation [1], I noticed that the driver's tear down handling > > is currently broken, something which can lead to memory leaks and > > potentially use-after-free issues on probe deferral and on driver > > unbind. > > > > Let's get this sorted before reworking driver. > > > > Note that the last patch has only been compile tested as I don't have > > access to a sdm845 device. > > > > Johan > I'll sound like a broken record, but: > > is there anyone in the world that is actively benefiting from this failed > experiment of using the ACPI tables that were shipped with these SoCs? > > There are so so so many shortcomings associated with it due to how Windows > drivers on these platforms know waaaay too much and largely use ACPI to > "bind driver x" and I simply think it doesn't make sense to continue > carrying this code forward given little use and no testing. > > Konrad > For what it is worth, I have agreed with your opinion on this every time I've read it. I am not the target audience of the question, but I'll at least give my personal (interpreted: uneducated? undesired?) opinion that the ACPI support in here adds little value and extra burden. Of course that topic is a bit independent of this series, but I'd be curious if a patchset removing the support would be welcomed or not by maintainers, so I'm stirring the pot by replying here :) Thanks, Andrew
On Mon, Nov 20, 2023 at 09:22:54AM -0600, Andrew Halaney wrote: > On Sat, Nov 18, 2023 at 12:47:30AM +0100, Konrad Dybcio wrote: > > On 17.11.2023 18:36, Johan Hovold wrote: > > > When reviewing the recently submitted series which reworks the dwc3 qcom > > > glue implementation [1], I noticed that the driver's tear down handling > > > is currently broken, something which can lead to memory leaks and > > > potentially use-after-free issues on probe deferral and on driver > > > unbind. > > > > > > Let's get this sorted before reworking driver. > > > > > > Note that the last patch has only been compile tested as I don't have > > > access to a sdm845 device. > > I'll sound like a broken record, but: > > > > is there anyone in the world that is actively benefiting from this failed > > experiment of using the ACPI tables that were shipped with these SoCs? > > > > There are so so so many shortcomings associated with it due to how Windows > > drivers on these platforms know waaaay too much and largely use ACPI to > > "bind driver x" and I simply think it doesn't make sense to continue > > carrying this code forward given little use and no testing. > For what it is worth, I have agreed with your opinion on this every time > I've read it. I am not the target audience of the question, but I'll at > least give my personal (interpreted: uneducated? undesired?) opinion > that the ACPI support in here adds little value and extra burden. > > Of course that topic is a bit independent of this series, but I'd be > curious if a patchset removing the support would be welcomed or not by > maintainers, so I'm stirring the pot by replying here :) I agree that if we can remove the ACPI hacks in here, we should try do so (e.g. given that no one really uses it anymore). As Andrew already mentioned, that is a separate issue not directly related to this series, though. Removing it before reworking the dwc3 binding [1] and adding multiport support [2] should simplify both of those series quite a bit, however. Johan [1] https://lore.kernel.org/all/20231016-dwc3-refactor-v1-0-ab4a84165470@quicinc.com/ [2] https://lore.kernel.org/all/20231007154806.605-1-quic_kriskura@quicinc.com/
On Mon, Nov 20, 2023 at 05:53:10PM +0100, Johan Hovold wrote: > On Mon, Nov 20, 2023 at 09:22:54AM -0600, Andrew Halaney wrote: > > On Sat, Nov 18, 2023 at 12:47:30AM +0100, Konrad Dybcio wrote: > > > On 17.11.2023 18:36, Johan Hovold wrote: > > > > When reviewing the recently submitted series which reworks the dwc3 qcom > > > > glue implementation [1], I noticed that the driver's tear down handling > > > > is currently broken, something which can lead to memory leaks and > > > > potentially use-after-free issues on probe deferral and on driver > > > > unbind. > > > > > > > > Let's get this sorted before reworking driver. > > > > > > > > Note that the last patch has only been compile tested as I don't have > > > > access to a sdm845 device. > > > > I'll sound like a broken record, but: > > > > > > is there anyone in the world that is actively benefiting from this failed > > > experiment of using the ACPI tables that were shipped with these SoCs? > > > > > > There are so so so many shortcomings associated with it due to how Windows > > > drivers on these platforms know waaaay too much and largely use ACPI to > > > "bind driver x" and I simply think it doesn't make sense to continue > > > carrying this code forward given little use and no testing. > > > For what it is worth, I have agreed with your opinion on this every time > > I've read it. I am not the target audience of the question, but I'll at > > least give my personal (interpreted: uneducated? undesired?) opinion > > that the ACPI support in here adds little value and extra burden. > > > > Of course that topic is a bit independent of this series, but I'd be > > curious if a patchset removing the support would be welcomed or not by > > maintainers, so I'm stirring the pot by replying here :) > > I agree that if we can remove the ACPI hacks in here, we should try do > so (e.g. given that no one really uses it anymore). > > As Andrew already mentioned, that is a separate issue not directly > related to this series, though. > > Removing it before reworking the dwc3 binding [1] and adding multiport > support [2] should simplify both of those series quite a bit, however. > > Johan > > [1] https://lore.kernel.org/all/20231016-dwc3-refactor-v1-0-ab4a84165470@quicinc.com/ > [2] https://lore.kernel.org/all/20231007154806.605-1-quic_kriskura@quicinc.com/ > So should I apply this series now or not? confused, greg k-h
On Tue, Nov 21, 2023 at 03:21:34PM +0100, Greg Kroah-Hartman wrote: > On Mon, Nov 20, 2023 at 05:53:10PM +0100, Johan Hovold wrote: > > On Mon, Nov 20, 2023 at 09:22:54AM -0600, Andrew Halaney wrote: > > > On Sat, Nov 18, 2023 at 12:47:30AM +0100, Konrad Dybcio wrote: > > > > On 17.11.2023 18:36, Johan Hovold wrote: > > > > > When reviewing the recently submitted series which reworks the dwc3 qcom > > > > > glue implementation [1], I noticed that the driver's tear down handling > > > > > is currently broken, something which can lead to memory leaks and > > > > > potentially use-after-free issues on probe deferral and on driver > > > > > unbind. > > > > > > > > > > Let's get this sorted before reworking driver. > > > > > > > > > > Note that the last patch has only been compile tested as I don't have > > > > > access to a sdm845 device. > > > > > > I'll sound like a broken record, but: > > > > > > > > is there anyone in the world that is actively benefiting from this failed > > > > experiment of using the ACPI tables that were shipped with these SoCs? > > I agree that if we can remove the ACPI hacks in here, we should try do > > so (e.g. given that no one really uses it anymore). > > > > As Andrew already mentioned, that is a separate issue not directly > > related to this series, though. > > > > Removing it before reworking the dwc3 binding [1] and adding multiport > > support [2] should simplify both of those series quite a bit, however. > > [1] https://lore.kernel.org/all/20231016-dwc3-refactor-v1-0-ab4a84165470@quicinc.com/ > > [2] https://lore.kernel.org/all/20231007154806.605-1-quic_kriskura@quicinc.com/ > > > > So should I apply this series now or not? Please do. Removing ACPI support should be done later if that's at all possible. Johan
On Tue, Nov 21, 2023 at 04:04:03PM +0100, Johan Hovold wrote: > On Tue, Nov 21, 2023 at 03:21:34PM +0100, Greg Kroah-Hartman wrote: > > On Mon, Nov 20, 2023 at 05:53:10PM +0100, Johan Hovold wrote: > > > On Mon, Nov 20, 2023 at 09:22:54AM -0600, Andrew Halaney wrote: > > > > On Sat, Nov 18, 2023 at 12:47:30AM +0100, Konrad Dybcio wrote: > > > > > On 17.11.2023 18:36, Johan Hovold wrote: > > > > > > When reviewing the recently submitted series which reworks the dwc3 qcom > > > > > > glue implementation [1], I noticed that the driver's tear down handling > > > > > > is currently broken, something which can lead to memory leaks and > > > > > > potentially use-after-free issues on probe deferral and on driver > > > > > > unbind. > > > > > > > > > > > > Let's get this sorted before reworking driver. > > > > > > > > > > > > Note that the last patch has only been compile tested as I don't have > > > > > > access to a sdm845 device. > > > > > > > > I'll sound like a broken record, but: > > > > > > > > > > is there anyone in the world that is actively benefiting from this failed > > > > > experiment of using the ACPI tables that were shipped with these SoCs? > > > > I agree that if we can remove the ACPI hacks in here, we should try do > > > so (e.g. given that no one really uses it anymore). > > > > > > As Andrew already mentioned, that is a separate issue not directly > > > related to this series, though. > > > > > > Removing it before reworking the dwc3 binding [1] and adding multiport > > > support [2] should simplify both of those series quite a bit, however. > > > > [1] https://lore.kernel.org/all/20231016-dwc3-refactor-v1-0-ab4a84165470@quicinc.com/ > > > [2] https://lore.kernel.org/all/20231007154806.605-1-quic_kriskura@quicinc.com/ > > > > > > > So should I apply this series now or not? > > Please do. Removing ACPI support should be done later if that's at all > possible. Great, now queued up, thanks. greg k-h