Re: crash in gart_unmap_page() with master snapshot (commit e1ef035d272e)
On Fri, Jan 04, 2019 at 09:53:18AM +0100, Christoph Hellwig wrote:
> Hi Michal,
>
> can you try the patch below?
The machine has been running with it for 12 hours now without any
apparent problem. Without the patch it crashed once after ~10 minutes
and once after ~3 hours (then I switched back to 4.20). Thanks a lot for
quick help.
Tested-by: Michal Kubecek
>
> ---
> From 6b22ae23a1971646dacc8a0ad313a6329a04cf98 Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig
> Date: Fri, 4 Jan 2019 09:50:33 +0100
> Subject: x86/amd_gart: fix unmapping of non-GART mappings
>
> In many cases we don't have to create a GART mapping at all, which
> also means there is nothing to unmap. Fix the range check that was
> incorrectly modified when removing the mapping_error method.
>
> Fixes: 9e8aa6b546 ("x86/amd_gart: remove the mapping_error dma_map_ops
> method")
> Reported-by: Michal Kubecek
> Signed-off-by: Christoph Hellwig
> ---
> arch/x86/kernel/amd_gart_64.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/amd_gart_64.c b/arch/x86/kernel/amd_gart_64.c
> index e0ff3ac8c127..2c0aa34af69c 100644
> --- a/arch/x86/kernel/amd_gart_64.c
> +++ b/arch/x86/kernel/amd_gart_64.c
> @@ -256,7 +256,15 @@ static void gart_unmap_page(struct device *dev,
> dma_addr_t dma_addr,
> int npages;
> int i;
>
> - if (dma_addr == DMA_MAPPING_ERROR ||
> + if (WARN_ON_ONCE(dma_addr == DMA_MAPPING_ERROR))
> + return;
> +
> + /*
> + * This driver will not always use a GART mapping, but might have
> + * created a direct mapping instead. If that is the case there is
> + * nothing to unmap here.
> + */
> + if (dma_addr < iommu_bus_base ||
> dma_addr >= iommu_bus_base + iommu_size)
> return;
>
> --
> 2.20.1
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] arm64: dts: stratix10: Add Stratix10 SMMU support
From: Thor Thayer
Now there are device tree clocks for the ARM64 SMMU,
add SMMU support to the Stratix10 Device Tree which
includes adding the SMMU node and adding IOMMU stream
ids to the SMMU peripherals.
Signed-off-by: Thor Thayer
---
arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 29 +++
1 file changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
index b2c9bb664595..e3f5eaa3657d 100644
--- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
@@ -161,6 +161,7 @@
tx-fifo-depth = <16384>;
rx-fifo-depth = <16384>;
snps,multicast-filter-bins = <256>;
+ iommus = < 1>;
status = "disabled";
};
@@ -177,6 +178,7 @@
tx-fifo-depth = <16384>;
rx-fifo-depth = <16384>;
snps,multicast-filter-bins = <256>;
+ iommus = < 2>;
status = "disabled";
};
@@ -193,6 +195,7 @@
tx-fifo-depth = <16384>;
rx-fifo-depth = <16384>;
snps,multicast-filter-bins = <256>;
+ iommus = < 3>;
status = "disabled";
};
@@ -303,6 +306,7 @@
clocks = < STRATIX10_L4_MP_CLK>,
< STRATIX10_SDMMC_CLK>;
clock-names = "biu", "ciu";
+ iommus = < 5>;
status = "disabled";
};
@@ -336,6 +340,29 @@
reg = <0xffd11000 0x1000>;
};
+ smmu: iommu@fa00 {
+ compatible = "arm,mmu-500", "arm,smmu-v2";
+ reg = <0xfa00 0x4>;
+ #global-interrupts = <2>;
+ #iommu-cells = <1>;
+ clocks = < STRATIX10_L4_MAIN_CLK>;
+ clock-names = "iommu";
+ interrupt-parent = <>;
+ interrupts = <0 128 4>, /* Global Secure Fault */
+ <0 129 4>, /* Global Non-secure Fault */
+ /* Non-secure Context Interrupts (32) */
+ <0 138 4>, <0 139 4>, <0 140 4>, <0 141 4>,
+ <0 142 4>, <0 143 4>, <0 144 4>, <0 145 4>,
+ <0 146 4>, <0 147 4>, <0 148 4>, <0 149 4>,
+ <0 150 4>, <0 151 4>, <0 152 4>, <0 153 4>,
+ <0 154 4>, <0 155 4>, <0 156 4>, <0 157 4>,
+ <0 158 4>, <0 159 4>, <0 160 4>, <0 161 4>,
+ <0 162 4>, <0 163 4>, <0 164 4>, <0 165 4>,
+ <0 166 4>, <0 167 4>, <0 168 4>, <0 169 4>;
+ stream-match-mask = <0x7ff0>;
+ status = "disabled";
+ };
+
spi0: spi@ffda4000 {
compatible = "snps,dw-apb-ssi";
#address-cells = <1>;
@@ -445,6 +472,7 @@
resets = < USB0_RESET>, < USB0_OCP_RESET>;
reset-names = "dwc2", "dwc2-ecc";
clocks = < STRATIX10_USB_CLK>;
+ iommus = < 6>;
status = "disabled";
};
@@ -457,6 +485,7 @@
resets = < USB1_RESET>, < USB1_OCP_RESET>;
reset-names = "dwc2", "dwc2-ecc";
clocks = < STRATIX10_USB_CLK>;
+ iommus = < 7>;
status = "disabled";
};
--
2.7.4
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3] crypto: talitos - fix ablkcipher for CONFIG_VMAP_STACK
On 1/4/2019 5:17 PM, Horia Geanta wrote:
> On 12/21/2018 10:07 AM, Christophe Leroy wrote:
> [snip]
>> IV cannot be on stack when CONFIG_VMAP_STACK is selected because the stack
>> cannot be DMA mapped anymore.
>> This looks better, thanks.
>
>> This patch copies the IV into the extended descriptor when iv is not
>> a valid linear address.
>>
> Though I am not sure the checks in place are enough.
>
>> Fixes: 4de9d0b547b9 ("crypto: talitos - Add ablkcipher algorithms")
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Christophe Leroy
>> ---
>> v3: Using struct edesc buffer.
>>
>> v2: Using per-request context.
> [snip]
>> +if (ivsize && !virt_addr_valid(iv))
>> +alloc_len += ivsize;
> [snip]
>>
>> +if (ivsize && !virt_addr_valid(iv))
> A more precise condition would be (!is_vmalloc_addr || is_vmalloc_addr(iv))
>
Sorry for the typo, I meant:
(!virt_addr_valid(iv) || is_vmalloc_addr(iv))
> It matches the checks in debug_dma_map_single() helper, though I am not sure
> they are enough to rule out all exceptions of DMA API.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3] crypto: talitos - fix ablkcipher for CONFIG_VMAP_STACK
On 12/21/2018 10:07 AM, Christophe Leroy wrote:
[snip]
> IV cannot be on stack when CONFIG_VMAP_STACK is selected because the stack
> cannot be DMA mapped anymore.
> This looks better, thanks.
> This patch copies the IV into the extended descriptor when iv is not
> a valid linear address.
>
Though I am not sure the checks in place are enough.
> Fixes: 4de9d0b547b9 ("crypto: talitos - Add ablkcipher algorithms")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Christophe Leroy
> ---
> v3: Using struct edesc buffer.
>
> v2: Using per-request context.
[snip]
> + if (ivsize && !virt_addr_valid(iv))
> + alloc_len += ivsize;
[snip]
>
> + if (ivsize && !virt_addr_valid(iv))
A more precise condition would be (!is_vmalloc_addr || is_vmalloc_addr(iv))
It matches the checks in debug_dma_map_single() helper, though I am not sure
they are enough to rule out all exceptions of DMA API.
> + iv = memcpy(((u8 *)edesc) + alloc_len - ivsize, iv, ivsize);
> +
> edesc->src_nents = src_nents;
> edesc->dst_nents = dst_nents;
> - edesc->iv_dma = iv_dma;
> + if (ivsize)
> + edesc->iv_dma = dma_map_single(dev, iv, ivsize, DMA_TO_DEVICE);
> + else
> + edesc->iv_dma = 0;
> +
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: crash in gart_unmap_page() with master snapshot (commit e1ef035d272e)
Hi Michal,
can you try the patch below?
---
>From 6b22ae23a1971646dacc8a0ad313a6329a04cf98 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Fri, 4 Jan 2019 09:50:33 +0100
Subject: x86/amd_gart: fix unmapping of non-GART mappings
In many cases we don't have to create a GART mapping at all, which
also means there is nothing to unmap. Fix the range check that was
incorrectly modified when removing the mapping_error method.
Fixes: 9e8aa6b546 ("x86/amd_gart: remove the mapping_error dma_map_ops method")
Reported-by: Michal Kubecek
Signed-off-by: Christoph Hellwig
---
arch/x86/kernel/amd_gart_64.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/amd_gart_64.c b/arch/x86/kernel/amd_gart_64.c
index e0ff3ac8c127..2c0aa34af69c 100644
--- a/arch/x86/kernel/amd_gart_64.c
+++ b/arch/x86/kernel/amd_gart_64.c
@@ -256,7 +256,15 @@ static void gart_unmap_page(struct device *dev, dma_addr_t
dma_addr,
int npages;
int i;
- if (dma_addr == DMA_MAPPING_ERROR ||
+ if (WARN_ON_ONCE(dma_addr == DMA_MAPPING_ERROR))
+ return;
+
+ /*
+* This driver will not always use a GART mapping, but might have
+* created a direct mapping instead. If that is the case there is
+* nothing to unmap here.
+*/
+ if (dma_addr < iommu_bus_base ||
dma_addr >= iommu_bus_base + iommu_size)
return;
--
2.20.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: iommu_intel or i915 regression in 4.18, 4.19.12 and drm-tip
Quoting Eric Wong (2019-01-04 03:06:26)
> Joonas Lahtinen wrote:
> > Quoting Eric Wong (2018-12-27 13:49:48)
> > > I just got a used Thinkpad X201 (Core i5 M 520, Intel QM57
> > > chipset) and hit some kernel panics while trying to view
> > > image/animation-intensive stuff in Firefox (X11) unless I use
> > > "iommu_intel=igfx_off".
> > >
> > > With Debian stable backport kernels, "linux-image-4.17.0-0.bpo.3-amd64"
> > > (4.17.17-1~bpo9+1) has no problems. But
> > > "linux-image-4.18.0-0.bpo.3-amd64"
> > > (4.18.20-2~bpo9+1) gives a blank screen before I can login via agetty
> > > and run startx.
>
> > Most confusing about this is that 4.17 would have worked to begin with,
> > without intel_iommu=igfx_off (unless it was the default for older
> > kernel?)
>
> Yeah, so the Debian bpo 4.17(.17) kernel did not set
> CONFIG_INTEL_IOMMU_DEFAULT_ON, so I didn't encounter problems.
> My self-built kernels all set CONFIG_INTEL_IOMMU_DEFAULT_ON.
So it's the case that IOMMU never worked on your machine.
My recommendation would be to simply use intel_iommu=igfx_off if you
need IOMMU.
Old hardware is known to have issues with IOMMU, and retroactively
enabling IOMMU on those machines just brings them up :/
Regards, Joonas
> Booting the Debian 4.17 kernel with "intel_iommu=on" gives the
> same hanging problem I hit with self-built 4.19.{12,13} kernels.
>
> I'm not sure how far back the problem goes (maybe forever),
> since I only got this hardware. Not sure what's the problem
> with Debian 4.18, either; but (self-built) 4.19.13 is fine w/o
> CONFIG_INTEL_IOMMU_DEFAULT_ON.
>
> Debian backports doesn't have kernels for 4.19 or 4.20, yet.
>
> > Did you maybe update other parts of the system while updating the
> > kernel?
>
> Definitely not; just the kernel + headers ("make bindeb-pkg)".
>
> > If you could attach full boot dmesg from working and non-working kernel +
> > have config file of both kernel's in Bugzilla. That'd be a good start!
>
> Sorry, I get anxiety attacks when it comes to logins and forms.
> Anyways, I managed to get the Debian kernel dmesg output uploaded
> with and without iommu_intel=on:
> https://bugs.freedesktop.org/attachment.cgi?bugid=109219
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
