Message ID | 20230526085402.394239-1-wenst@chromium.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp327802vqr; Fri, 26 May 2023 02:08:59 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6ZeW2QWZUFvE735uEu02nX5DYYVty+6aOhiRbTtJXXI3UgWw8TttlE8wAeSPd7GWkZn9pR X-Received: by 2002:a05:6a00:2308:b0:645:c730:f826 with SMTP id h8-20020a056a00230800b00645c730f826mr2990409pfh.24.1685092139549; Fri, 26 May 2023 02:08:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685092139; cv=none; d=google.com; s=arc-20160816; b=UiXnxCWMDC7HwdlmSBHxGLJdrb3hsGMOnc8mXCcesbXUYpwXX1R6iJ5079f3Ad+YNL I5pQ5EJnrBaboj7EswjfuKARnFhB5gNIK8ZkLJdYcosEhz3FmojNbtVFS3UTg7nnSyrW 346vBQBxaamIrLRWbBq7xeNmSpOuqioYToke4YYuCHxwt2fudSQH9ZpcVURt5TwxLvUZ wpkkpOUH2UL3KBVWSGmJS+GeXSO/jIQchpVbBI1q72VK5rb5TbqCUW5pOXoOn+jkitx0 1Is0s7Mm2M1H1o0frZqhUkJ4NFtPMB1r8LK/gCtsdKaFmniDR+jO5YFmag3WllJaeVGr E1iw== 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=5E1O6F8XFMIurLCllD6JGMVmsuqHQFoAO58kkivfIrk=; b=laYNzykKP+jqx+NEBEJZ0P8mnS53XNt422qSnyDVvN31L3JWLY+X1DsqjCd3wBw4Cn LJkDbnouVLUn2fVRByQNIHnW2yoM+o4g5n3f5dgHTRrG0CvKdyPL6VRJLIVcvVWjRsAy CVoRQcQ7a8rp7f8OW92u73l+No3oxohgWV3HLY7DWOixRjhyTtepkTfPd/EICtlsqw66 xH9I9jEzJbcS/tgj6BjFeFcXMOHAtkYRShCV49OxlNs2pzvbzJQXwq6O86eGL0j9UdpJ ox9+MjWkUop/8mxlnjomxwj7XOydMRZubmuQF93G+xIdQRJ9Mh2CIONf2iioKy9x3izK VwSA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=UnwWb9DC; 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=chromium.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f25-20020a637559000000b0053b64127cddsi3217936pgn.212.2023.05.26.02.08.27; Fri, 26 May 2023 02:08:59 -0700 (PDT) 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=@chromium.org header.s=google header.b=UnwWb9DC; 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=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242730AbjEZIyS (ORCPT <rfc822;zhanglyra.2023@gmail.com> + 99 others); Fri, 26 May 2023 04:54:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48186 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242674AbjEZIyP (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 26 May 2023 04:54:15 -0400 Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 26D3099 for <linux-kernel@vger.kernel.org>; Fri, 26 May 2023 01:54:14 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id d2e1a72fcca58-64d604cc0aaso572072b3a.2 for <linux-kernel@vger.kernel.org>; Fri, 26 May 2023 01:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1685091253; x=1687683253; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=5E1O6F8XFMIurLCllD6JGMVmsuqHQFoAO58kkivfIrk=; b=UnwWb9DC2h863iCSINm0c8593AEcbSTqSTS0nIydcAQxy4ijGiC1l8g3dq3zHEueQa mvKy8j9rxBeD0sO+ZHFGrNtQ0nKiEHGf8VE+zNkFwoOREZKXTqlYsGRWB11GiqxGbDaR Kw33o3SFcqbx6F4JAKf54w+CVZiNXn9MFDrCQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685091253; x=1687683253; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5E1O6F8XFMIurLCllD6JGMVmsuqHQFoAO58kkivfIrk=; b=alrDMTKk1fgnE7G2RIh1mV9HzZKo8dwPDcdDVos3P87MRVTXgBbx+Qp59AB1z6KWgH wKbieN5a/A8+gzRsi0PlADBveyiaVsg9cgeH/+bdPF1qmKEY8SelqdmSqLaTpWcs8z/T e63VdelVu5LZCZeOmYgXJZDL+AiHjh3/2Xifaq6E63P4UiSauHZTo5DOdpuGtvkFuoNR EhowiZ2egxWI2HpqgPG3zy4WP2i8x96KCR3CvSHLHfBVBaJS6KRw1M79x63hzhJI4hYE i7YmQe4tlXViEOLq5FMDXNeImpX2d6KT0mshXLAGEMNrp7XpIjPAbODynff9GfS25mEz kKmA== X-Gm-Message-State: AC+VfDzsANDZmv9qs2NIqQaTyzwPau/z5/qe/g6sh95MsuYeGJRlmWWr Fh2DIRsO7uzf7dDX0WZjXsxphg== X-Received: by 2002:a05:6a00:218e:b0:64d:3227:b806 with SMTP id h14-20020a056a00218e00b0064d3227b806mr2748121pfi.33.1685091253571; Fri, 26 May 2023 01:54:13 -0700 (PDT) Received: from wenstp920.tpe.corp.google.com ([2401:fa00:1:10:17b9:e0b5:a956:4510]) by smtp.gmail.com with ESMTPSA id l14-20020a62be0e000000b006460751222asm2344166pff.38.2023.05.26.01.54.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 May 2023 01:54:13 -0700 (PDT) From: Chen-Yu Tsai <wenst@chromium.org> To: Yong Wu <yong.wu@mediatek.com>, Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>, Robin Murphy <robin.murphy@arm.com>, Matthias Brugger <matthias.bgg@gmail.com>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: Chen-Yu Tsai <wenst@chromium.org>, iommu@lists.linux.dev, linux-mediatek@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH RFC] iommu/mediatek: Flush IOTLB completely only if domain has been attached Date: Fri, 26 May 2023 16:53:59 +0800 Message-ID: <20230526085402.394239-1-wenst@chromium.org> X-Mailer: git-send-email 2.41.0.rc0.172.g3f132b7071-goog MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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?1766947175761917896?= X-GMAIL-MSGID: =?utf-8?q?1766947175761917896?= |
Series |
[RFC] iommu/mediatek: Flush IOTLB completely only if domain has been attached
|
|
Commit Message
Chen-Yu Tsai
May 26, 2023, 8:53 a.m. UTC
If an IOMMU domain was never attached, it lacks any linkage to the
actual IOMMU hardware. Attempting to do flush_iotlb_all() on it will
result in a NULL pointer dereference. This seems to happen after the
recent IOMMU core rework in v6.4-rc1.
Unable to handle kernel read from unreadable memory at virtual address 0000000000000018
Call trace:
mtk_iommu_flush_iotlb_all+0x20/0x80
iommu_create_device_direct_mappings.part.0+0x13c/0x230
iommu_setup_default_domain+0x29c/0x4d0
iommu_probe_device+0x12c/0x190
of_iommu_configure+0x140/0x208
of_dma_configure_id+0x19c/0x3c0
platform_dma_configure+0x38/0x88
really_probe+0x78/0x2c0
Check if the "bank" field has been filled in before actually attempting
the IOTLB flush to avoid it. The IOTLB is also flushed when the device
comes out of runtime suspend, so it should have a clean initial state.
Fixes: 08500c43d4f7 ("iommu/mediatek: Adjust the structure")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
I think this is a valid fix, but I'm not very familiar with the hardware
or the design of the driver. The ARM SMMU drivers seem to do this as well.
drivers/iommu/mtk_iommu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Comments
Il 26/05/23 10:53, Chen-Yu Tsai ha scritto: > If an IOMMU domain was never attached, it lacks any linkage to the > actual IOMMU hardware. Attempting to do flush_iotlb_all() on it will > result in a NULL pointer dereference. This seems to happen after the > recent IOMMU core rework in v6.4-rc1. > > Unable to handle kernel read from unreadable memory at virtual address 0000000000000018 > Call trace: > mtk_iommu_flush_iotlb_all+0x20/0x80 > iommu_create_device_direct_mappings.part.0+0x13c/0x230 > iommu_setup_default_domain+0x29c/0x4d0 > iommu_probe_device+0x12c/0x190 > of_iommu_configure+0x140/0x208 > of_dma_configure_id+0x19c/0x3c0 > platform_dma_configure+0x38/0x88 > really_probe+0x78/0x2c0 > > Check if the "bank" field has been filled in before actually attempting > the IOTLB flush to avoid it. The IOTLB is also flushed when the device > comes out of runtime suspend, so it should have a clean initial state. > > Fixes: 08500c43d4f7 ("iommu/mediatek: Adjust the structure") > Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Not only ARM SMMU does this, others are doing the same, some in a different form (walking a list)... So I agree with this being a valid fix. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > --- > > I think this is a valid fix, but I'm not very familiar with the hardware > or the design of the driver. The ARM SMMU drivers seem to do this as well. > > drivers/iommu/mtk_iommu.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c > index aecc7d154f28..e93906d6e112 100644 > --- a/drivers/iommu/mtk_iommu.c > +++ b/drivers/iommu/mtk_iommu.c > @@ -781,7 +781,8 @@ static void mtk_iommu_flush_iotlb_all(struct iommu_domain *domain) > { > struct mtk_iommu_domain *dom = to_mtk_domain(domain); > > - mtk_iommu_tlb_flush_all(dom->bank->parent_data); > + if (dom->bank) > + mtk_iommu_tlb_flush_all(dom->bank->parent_data); > } > > static void mtk_iommu_iotlb_sync(struct iommu_domain *domain,
On Fri, 2023-05-26 at 16:53 +0800, Chen-Yu Tsai wrote: > > If an IOMMU domain was never attached, it lacks any linkage to the > actual IOMMU hardware. Attempting to do flush_iotlb_all() on it will > result in a NULL pointer dereference. This seems to happen after the > recent IOMMU core rework in v6.4-rc1. > > Unable to handle kernel read from unreadable memory at virtual > address 0000000000000018 > Call trace: > mtk_iommu_flush_iotlb_all+0x20/0x80 > iommu_create_device_direct_mappings.part.0+0x13c/0x230 > iommu_setup_default_domain+0x29c/0x4d0 > iommu_probe_device+0x12c/0x190 > of_iommu_configure+0x140/0x208 > of_dma_configure_id+0x19c/0x3c0 > platform_dma_configure+0x38/0x88 > really_probe+0x78/0x2c0 > > Check if the "bank" field has been filled in before actually > attempting > the IOTLB flush to avoid it. The IOTLB is also flushed when the > device > comes out of runtime suspend, so it should have a clean initial > state. > > Fixes: 08500c43d4f7 ("iommu/mediatek: Adjust the structure") The interface "iommu_setup_default_domain" doesn't exist in v6.4-rc1. This is a fixes for linux-next. And the Fixes tag should be: 152431e4fe7f ("iommu: Do iommu_group_create_direct_mappings() before attach") then: Reviewed-by: Yong Wu <yong.wu@mediatek.com> Thanks very much. > Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> > --- > > I think this is a valid fix, but I'm not very familiar with the > hardware > or the design of the driver. The ARM SMMU drivers seem to do this as > well. > > drivers/iommu/mtk_iommu.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c > index aecc7d154f28..e93906d6e112 100644 > --- a/drivers/iommu/mtk_iommu.c > +++ b/drivers/iommu/mtk_iommu.c > @@ -781,7 +781,8 @@ static void mtk_iommu_flush_iotlb_all(struct > iommu_domain *domain) > { > struct mtk_iommu_domain *dom = to_mtk_domain(domain); > > - mtk_iommu_tlb_flush_all(dom->bank->parent_data); > + if (dom->bank) > + mtk_iommu_tlb_flush_all(dom->bank->parent_data); > } > > static void mtk_iommu_iotlb_sync(struct iommu_domain *domain, > -- > 2.41.0.rc0.172.g3f132b7071-goog
On Fri, May 26, 2023 at 04:53:59PM +0800, Chen-Yu Tsai wrote: > Fixes: 08500c43d4f7 ("iommu/mediatek: Adjust the structure") > Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Applied for 6.4, thanks.
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c index aecc7d154f28..e93906d6e112 100644 --- a/drivers/iommu/mtk_iommu.c +++ b/drivers/iommu/mtk_iommu.c @@ -781,7 +781,8 @@ static void mtk_iommu_flush_iotlb_all(struct iommu_domain *domain) { struct mtk_iommu_domain *dom = to_mtk_domain(domain); - mtk_iommu_tlb_flush_all(dom->bank->parent_data); + if (dom->bank) + mtk_iommu_tlb_flush_all(dom->bank->parent_data); } static void mtk_iommu_iotlb_sync(struct iommu_domain *domain,