Message ID | 20221122143949.3493104-1-nfraprado@collabora.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp2249755wrr; Tue, 22 Nov 2022 06:50:40 -0800 (PST) X-Google-Smtp-Source: AA0mqf5WxXu7U7lAj7YwR7W45FAeZTkjmCS3/dEKPGp/P/Zz2cmM+ejcovjb0BzFY/v+cj5OPzlO X-Received: by 2002:a17:906:802:b0:7b5:6f12:f2c9 with SMTP id e2-20020a170906080200b007b56f12f2c9mr9950674ejd.739.1669128640739; Tue, 22 Nov 2022 06:50:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669128640; cv=none; d=google.com; s=arc-20160816; b=fR7zApCXEa3VTRCVNOAwdn0k3trMwy6/xBRTWchQuqMd8ZLwaeuTuOgpcPpaszRGdp eFfH+m+nfmpRH/v0eT35b2Fz7EihBpSwLeGyn92bgNFtBZ2B0MmAnILPuoUTGwHsi5Le 0b4qp5u6JDmwjwbcTSCOE8tU7oV3peMcGWi+lqFlnd1LKK0Vy8YvG0Eib/TzgFVMHVA+ bv+26D7QCnCrvtClMLltl7K0qiSo0cNg/AOIAIBSonmYywd49w9ARuIbawhVP30PIgAR hSK/YDg/M5WVCXfdjxwWEyfpS9mT2/LMmVtNBT23A2Y1WfSFbx1S172INdf3zimvi3nU Vl8g== 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=5lHYnQZHxeiRRl4b0PnKeYL4tG2hHBxi0AvXaaO1PGE=; b=z4xJU5CVBYZtMCLRJAe1n0VkTeTvVKQeDIcmAiMfZiM2/YFjCmX4xfrxMxGljTBZ8/ f2kMFR3QS+CXXreAi54NrhiRQlSb7nfiSzkRrRHdf3850c52gIq4Mkwzt6sodtQEQGN0 JF1Ig5ZsSzZtR7j5qOAJWwoSiPjEJBGlkRfWMHCioB1x9boq9n2PlbIdM0sPZql+FW6C OZP01hLWWmtFH5Q3MPzXifmYhwkBPBUtuPoYXttZwdrjw7PtcgkVCqvebJ5WSTy2ZKNB g52Ejeear6isJK/n9JaCRwqU0baHwamf6NQWxts8cEVwjUaLTKZVlNtEhDb8aNLMg43z b8Fg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b="kU5Urq/M"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id dm21-20020a05640222d500b004619acbc70fsi10457232edb.505.2022.11.22.06.50.14; Tue, 22 Nov 2022 06:50:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b="kU5Urq/M"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232483AbiKVOj7 (ORCPT <rfc822;cjcooper78@gmail.com> + 99 others); Tue, 22 Nov 2022 09:39:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56516 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232132AbiKVOj5 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 22 Nov 2022 09:39:57 -0500 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 696D62B1AD for <linux-kernel@vger.kernel.org>; Tue, 22 Nov 2022 06:39:56 -0800 (PST) Received: from notapiano.myfiosgateway.com (unknown [IPv6:2600:4041:5b1a:cd00:524d:e95d:1a9c:492a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: nfraprado) by madras.collabora.co.uk (Postfix) with ESMTPSA id 41CCD6602A9F; Tue, 22 Nov 2022 14:39:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1669127994; bh=1st3ieDQkiQof93MDMgMLlXqhvQ5AE2T3/Zoqzl8ov8=; h=From:To:Cc:Subject:Date:From; b=kU5Urq/M4qqcdMaCl2c0kq/ou+3e6P7PabNaY8VO/7TPsRvQ8TCfLJGhleL2bfKE5 +B/3w6m44bKrYIDchckcf5fidaGJnAqzhq/LJ3dQtAZGWO5uA/UK6Z3JXLNW/Cxge9 KbkI9KORE/oT+bWmZtbh1CRtWLIinkqcAsc7EwL41ElnSk46NJzB46IOyXd+QArvCr pyQZtQUbpxotQB7TgD97Ij7Iti1qVGIdjQnC9CdX5/8foWYA8emEBGfpleiNUSewNt lM3wIzVsNLX5UxXZphC3a2HkGj4L9M55pdoMQ26KDP6LRfz3mjZ6xcuJ7aeioZfcZL C7Q3E4HSeCCnw== From: =?utf-8?b?TsOtY29sYXMgRi4gUi4gQS4gUHJhZG8=?= <nfraprado@collabora.com> To: Chun-Kuang Hu <chunkuang.hu@kernel.org> Cc: kernel@collabora.com, "Nancy . Lin" <nancy.lin@mediatek.com>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, =?utf-8?b?TsOtY29sYXMgRi4gUi4gQS4gUHJhZG8=?= <nfraprado@collabora.com>, CK Hu <ck.hu@mediatek.com>, Daniel Kurtz <djkurtz@chromium.org>, Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@gmail.com>, Mao Huang <littlecvr@chromium.org>, Matthias Brugger <matthias.bgg@gmail.com>, Philipp Zabel <p.zabel@pengutronix.de>, YT Shen <yt.shen@mediatek.com>, dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org Subject: [PATCH v2] drm/mediatek: Clean dangling pointer on bind error path Date: Tue, 22 Nov 2022 09:39:49 -0500 Message-Id: <20221122143949.3493104-1-nfraprado@collabora.com> X-Mailer: git-send-email 2.38.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750208233434182843?= X-GMAIL-MSGID: =?utf-8?q?1750208233434182843?= |
Series |
[v2] drm/mediatek: Clean dangling pointer on bind error path
|
|
Commit Message
Nícolas F. R. A. Prado
Nov. 22, 2022, 2:39 p.m. UTC
mtk_drm_bind() can fail, in which case drm_dev_put() is called,
destroying the drm_device object. However a pointer to it was still
being held in the private object, and that pointer would be passed along
to DRM in mtk_drm_sys_prepare() if a suspend were triggered at that
point, resulting in a panic. Clean the pointer when destroying the
object in the error path to prevent this from happening.
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
---
Changes in v2:
- Added Fixes tag
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
1 file changed, 1 insertion(+)
Comments
Il 22/11/22 15:39, Nícolas F. R. A. Prado ha scritto: > mtk_drm_bind() can fail, in which case drm_dev_put() is called, > destroying the drm_device object. However a pointer to it was still > being held in the private object, and that pointer would be passed along > to DRM in mtk_drm_sys_prepare() if a suspend were triggered at that > point, resulting in a panic. Clean the pointer when destroying the > object in the error path to prevent this from happening. > > Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> > > --- > > Changes in v2: > - Added Fixes tag > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > index 39a42dc8fb85..a21ff1b3258c 100644 > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > @@ -514,6 +514,7 @@ static int mtk_drm_bind(struct device *dev) > err_deinit: > mtk_drm_kms_deinit(drm); > err_free: > + private->drm = NULL; Sorry for not noticing that in v1, but I've rechecked this function and, while this commit does indeed actually solve the described issue, I think it's incomplete. A few lines before, we have a loop that sets private->all_drm_private[i]->drm = drm; ...so here you should do... private->drm = NULL; while (i--) /* a for loop will also do, your choice */ private->all_drm_private[i]->drm = NULL; That makes sure that you cleanup *everything* :-) Cheers, Angelo
On Wed, Nov 23, 2022 at 10:15:25AM +0100, AngeloGioacchino Del Regno wrote: > Il 22/11/22 15:39, Nícolas F. R. A. Prado ha scritto: > > mtk_drm_bind() can fail, in which case drm_dev_put() is called, > > destroying the drm_device object. However a pointer to it was still > > being held in the private object, and that pointer would be passed along > > to DRM in mtk_drm_sys_prepare() if a suspend were triggered at that > > point, resulting in a panic. Clean the pointer when destroying the > > object in the error path to prevent this from happening. > > > > Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") > > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> > > > > --- > > > > Changes in v2: > > - Added Fixes tag > > > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > > index 39a42dc8fb85..a21ff1b3258c 100644 > > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > > @@ -514,6 +514,7 @@ static int mtk_drm_bind(struct device *dev) > > err_deinit: > > mtk_drm_kms_deinit(drm); > > err_free: > > + private->drm = NULL; > > Sorry for not noticing that in v1, but I've rechecked this function and, while this > commit does indeed actually solve the described issue, I think it's incomplete. > > A few lines before, we have a loop that sets > > private->all_drm_private[i]->drm = drm; Actually that line only exists with [1] applied, but that commit hasn't been merged as of yet. I debated whether it would be better to send this fix as is, or ask Nancy Lin to add the tweaked fix you mention below to that series, but sending this fix as is seemed better since it can be backported to older kernel versions. So assuming this commit gets merged first, Nancy should make that tweak you mentioned below to ensure all the pointers are zeroed out, which is why I've added Nancy to CC. (As a side note, given that only the mmsys with drm_master = true would ever call the drm suspend helper, even this patch as is is enough to avoid the panic even with that series applied, still we should zero out all pointers for good measure) [1] https://lore.kernel.org/linux-mediatek/20221107072413.16178-6-nancy.lin@mediatek.com/ Thanks, Nícolas > > ...so here you should do... > > private->drm = NULL; > > while (i--) /* a for loop will also do, your choice */ > private->all_drm_private[i]->drm = NULL; > > That makes sure that you cleanup *everything* :-) > > Cheers, > Angelo >
Il 25/11/22 17:34, Nícolas F. R. A. Prado ha scritto: > On Wed, Nov 23, 2022 at 10:15:25AM +0100, AngeloGioacchino Del Regno wrote: >> Il 22/11/22 15:39, Nícolas F. R. A. Prado ha scritto: >>> mtk_drm_bind() can fail, in which case drm_dev_put() is called, >>> destroying the drm_device object. However a pointer to it was still >>> being held in the private object, and that pointer would be passed along >>> to DRM in mtk_drm_sys_prepare() if a suspend were triggered at that >>> point, resulting in a panic. Clean the pointer when destroying the >>> object in the error path to prevent this from happening. >>> >>> Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") >>> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> >>> >>> --- >>> >>> Changes in v2: >>> - Added Fixes tag >>> >>> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c >>> index 39a42dc8fb85..a21ff1b3258c 100644 >>> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c >>> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c >>> @@ -514,6 +514,7 @@ static int mtk_drm_bind(struct device *dev) >>> err_deinit: >>> mtk_drm_kms_deinit(drm); >>> err_free: >>> + private->drm = NULL; >> >> Sorry for not noticing that in v1, but I've rechecked this function and, while this >> commit does indeed actually solve the described issue, I think it's incomplete. >> >> A few lines before, we have a loop that sets >> >> private->all_drm_private[i]->drm = drm; > > Actually that line only exists with [1] applied, but that commit hasn't been > merged as of yet. I debated whether it would be better to send this fix as is, > or ask Nancy Lin to add the tweaked fix you mention below to that series, but > sending this fix as is seemed better since it can be backported to older kernel > versions. > > So assuming this commit gets merged first, Nancy should make that tweak you > mentioned below to ensure all the pointers are zeroed out, which is why I've > added Nancy to CC. (As a side note, given that only the mmsys with drm_master = > true would ever call the drm suspend helper, even this patch as is is enough to > avoid the panic even with that series applied, still we should zero out all > pointers for good measure) > > [1] https://lore.kernel.org/linux-mediatek/20221107072413.16178-6-nancy.lin@mediatek.com/ > Sorry about that, you're right - the proposed fix is for the commit you linked, I got confused somehow. This means that you get my Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cheers!
Hi, Nicolas: Nícolas F. R. A. Prado <nfraprado@collabora.com> 於 2022年11月22日 週二 下午10:39寫道: > > mtk_drm_bind() can fail, in which case drm_dev_put() is called, > destroying the drm_device object. However a pointer to it was still > being held in the private object, and that pointer would be passed along > to DRM in mtk_drm_sys_prepare() if a suspend were triggered at that > point, resulting in a panic. Clean the pointer when destroying the > object in the error path to prevent this from happening. Applied to mediatek-drm-next [1], thanks. [1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next Regards, Chun-Kuang. > > Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> > > --- > > Changes in v2: > - Added Fixes tag > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > index 39a42dc8fb85..a21ff1b3258c 100644 > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > @@ -514,6 +514,7 @@ static int mtk_drm_bind(struct device *dev) > err_deinit: > mtk_drm_kms_deinit(drm); > err_free: > + private->drm = NULL; > drm_dev_put(drm); > return ret; > } > -- > 2.38.1 >
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c index 39a42dc8fb85..a21ff1b3258c 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c @@ -514,6 +514,7 @@ static int mtk_drm_bind(struct device *dev) err_deinit: mtk_drm_kms_deinit(drm); err_free: + private->drm = NULL; drm_dev_put(drm); return ret; }