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 <[email protected]>
---
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
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 <[email protected]>
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 <[email protected]>
> ---
>
> 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 <[email protected]>
Thanks very much.
> Signed-off-by: Chen-Yu Tsai <[email protected]>
> ---
>
> 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 <[email protected]>
Applied for 6.4, thanks.