* [PATCH] dma: Fix max PFN arithmetic overflow on 32 bit systems @ 2020-03-02 18:16 Alexander Dahl 2020-03-18 9:41 ` Alexander Dahl 2020-03-19 13:50 ` Robin Murphy 0 siblings, 2 replies; 7+ messages in thread From: Alexander Dahl @ 2020-03-02 18:16 UTC (permalink / raw) To: x86 Cc: Alan Jenkins, linux-kernel, iommu, Ingo Molnar, Borislav Petkov, H . Peter Anvin, Thomas Gleixner For ARCH=x86 (32 bit) when you set CONFIG_IOMMU_INTEL since c5a5dc4cbbf4 ("iommu/vt-d: Don't switch off swiotlb if bounce page is used") there's a dependency on CONFIG_SWIOTLB, which was not necessarily active before. The init code for swiotlb in 'pci_swiotlb_detect_4gb()' compares something against MAX_DMA32_PFN to decide if it should be active. However that define suffers from an arithmetic overflow since 1b7e03ef7570 ("x86, NUMA: Enable emulation on 32bit too") when it was first made visible to x86_32. The effect is at boot time 64 MiB (default size) were allocated for bounce buffers now, which is a noticeable amount of memory on small systems. We noticed this effect on the fli4l Linux distribution when migrating from kernel v4.19 (LTS) to v5.4 (LTS) on boards like pcengines ALIX 2D3 with 256 MiB memory for example: Linux version 5.4.22 (buildroot@buildroot) (gcc version 7.3.0 (Buildroot 2018.02.8)) #1 SMP Mon Nov 26 23:40:00 CET 2018 … Memory: 183484K/261756K available (4594K kernel code, 393K rwdata, 1660K rodata, 536K init, 456K bss , 78272K reserved, 0K cma-reserved, 0K highmem) … PCI-DMA: Using software bounce buffering for IO (SWIOTLB) software IO TLB: mapped [mem 0x0bb78000-0x0fb78000] (64MB) The initial analysis and the suggested fix was done by user 'sourcejedi' at stackoverflow and explicitly marked as GPLv2 for inclusion in the Linux kernel: https://unix.stackexchange.com/a/520525/50007 Fixes: https://web.nettworks.org/bugs/browse/FFL-2560 Fixes: https://unix.stackexchange.com/q/520065/50007 Suggested-by: Alan Jenkins <alan.christopher.jenkins@gmail.com> Signed-off-by: Alexander Dahl <post@lespocky.de> --- We tested this in qemu and on real hardware with fli4l on top of v5.4, v5.5, and v5.6-rc kernels, but only as far as the reserved memory goes. The patch itself is based on v5.6-rc3 (IIRC). A quick grep over the kernel code showed me this define MAX_DMA32_PFN is used in other places as well. I would appreciate feedback on this, because I can not oversee all side effects this might have?! Thanks again to Alan who proposed the fix, and for his permission to send it upstream. Greets Alex --- arch/x86/include/asm/dma.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/dma.h b/arch/x86/include/asm/dma.h index 00f7cf45e699..e25514eca8d6 100644 --- a/arch/x86/include/asm/dma.h +++ b/arch/x86/include/asm/dma.h @@ -74,7 +74,7 @@ #define MAX_DMA_PFN ((16UL * 1024 * 1024) >> PAGE_SHIFT) /* 4GB broken PCI/AGP hardware bus master zone */ -#define MAX_DMA32_PFN ((4UL * 1024 * 1024 * 1024) >> PAGE_SHIFT) +#define MAX_DMA32_PFN (4UL * ((1024 * 1024 * 1024) >> PAGE_SHIFT)) #ifdef CONFIG_X86_32 /* The maximum address that we can perform a DMA transfer to on this platform */ -- 2.20.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] dma: Fix max PFN arithmetic overflow on 32 bit systems 2020-03-02 18:16 [PATCH] dma: Fix max PFN arithmetic overflow on 32 bit systems Alexander Dahl @ 2020-03-18 9:41 ` Alexander Dahl 2020-03-19 13:50 ` Robin Murphy 1 sibling, 0 replies; 7+ messages in thread From: Alexander Dahl @ 2020-03-18 9:41 UTC (permalink / raw) To: x86 Cc: Alan Jenkins, linux-kernel, iommu, Ingo Molnar, Borislav Petkov, H . Peter Anvin, Thomas Gleixner, Alexander Dahl [-- Attachment #1.1: Type: text/plain, Size: 3650 bytes --] Hei hei, gentle ping on this patch from two weeks ago. Did anyone have time to look into it? Did I miss someone in Cc or sent it to the wrong lists maybe? On Mon, Mar 02, 2020 at 07:16:12PM +0100, Alexander Dahl wrote: > For ARCH=x86 (32 bit) when you set CONFIG_IOMMU_INTEL since c5a5dc4cbbf4 > ("iommu/vt-d: Don't switch off swiotlb if bounce page is used") there's > a dependency on CONFIG_SWIOTLB, which was not necessarily active before. > > The init code for swiotlb in 'pci_swiotlb_detect_4gb()' compares > something against MAX_DMA32_PFN to decide if it should be active. > However that define suffers from an arithmetic overflow since > 1b7e03ef7570 ("x86, NUMA: Enable emulation on 32bit too") when it was > first made visible to x86_32. > > The effect is at boot time 64 MiB (default size) were allocated for > bounce buffers now, which is a noticeable amount of memory on small > systems. We noticed this effect on the fli4l Linux distribution when > migrating from kernel v4.19 (LTS) to v5.4 (LTS) on boards like pcengines > ALIX 2D3 with 256 MiB memory for example: > > Linux version 5.4.22 (buildroot@buildroot) (gcc version 7.3.0 (Buildroot 2018.02.8)) #1 SMP Mon Nov 26 23:40:00 CET 2018 > … > Memory: 183484K/261756K available (4594K kernel code, 393K rwdata, 1660K rodata, 536K init, 456K bss , 78272K reserved, 0K cma-reserved, 0K highmem) > … > PCI-DMA: Using software bounce buffering for IO (SWIOTLB) > software IO TLB: mapped [mem 0x0bb78000-0x0fb78000] (64MB) > > The initial analysis and the suggested fix was done by user 'sourcejedi' > at stackoverflow and explicitly marked as GPLv2 for inclusion in the > Linux kernel: > > https://unix.stackexchange.com/a/520525/50007 > > Fixes: https://web.nettworks.org/bugs/browse/FFL-2560 > Fixes: https://unix.stackexchange.com/q/520065/50007 > Suggested-by: Alan Jenkins <alan.christopher.jenkins@gmail.com> > Signed-off-by: Alexander Dahl <post@lespocky.de> > --- > We tested this in qemu and on real hardware with fli4l on top of v5.4, > v5.5, and v5.6-rc kernels, but only as far as the reserved memory goes. > The patch itself is based on v5.6-rc3 (IIRC). We had no complaints of our fli4l users, since we applied this patch to our distribution kernels. Thanks & greets Alex > > A quick grep over the kernel code showed me this define MAX_DMA32_PFN is > used in other places as well. I would appreciate feedback on this, > because I can not oversee all side effects this might have?! > > Thanks again to Alan who proposed the fix, and for his permission to > send it upstream. > > Greets > Alex > --- > arch/x86/include/asm/dma.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/include/asm/dma.h b/arch/x86/include/asm/dma.h > index 00f7cf45e699..e25514eca8d6 100644 > --- a/arch/x86/include/asm/dma.h > +++ b/arch/x86/include/asm/dma.h > @@ -74,7 +74,7 @@ > #define MAX_DMA_PFN ((16UL * 1024 * 1024) >> PAGE_SHIFT) > > /* 4GB broken PCI/AGP hardware bus master zone */ > -#define MAX_DMA32_PFN ((4UL * 1024 * 1024 * 1024) >> PAGE_SHIFT) > +#define MAX_DMA32_PFN (4UL * ((1024 * 1024 * 1024) >> PAGE_SHIFT)) > > #ifdef CONFIG_X86_32 > /* The maximum address that we can perform a DMA transfer to on this platform */ > -- > 2.20.1 -- /"\ ASCII RIBBON | »With the first link, the chain is forged. The first \ / CAMPAIGN | speech censured, the first thought forbidden, the X AGAINST | first freedom denied, chains us all irrevocably.« / \ HTML MAIL | (Jean-Luc Picard, quoting Judge Aaron Satie) [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 156 bytes --] _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] dma: Fix max PFN arithmetic overflow on 32 bit systems 2020-03-02 18:16 [PATCH] dma: Fix max PFN arithmetic overflow on 32 bit systems Alexander Dahl 2020-03-18 9:41 ` Alexander Dahl @ 2020-03-19 13:50 ` Robin Murphy 2020-03-19 15:31 ` Alexander Dahl 1 sibling, 1 reply; 7+ messages in thread From: Robin Murphy @ 2020-03-19 13:50 UTC (permalink / raw) To: Alexander Dahl, x86 Cc: linux-kernel, iommu, Alan Jenkins, Ingo Molnar, Borislav Petkov, H . Peter Anvin, Thomas Gleixner On 2020-03-02 6:16 pm, Alexander Dahl wrote: > For ARCH=x86 (32 bit) when you set CONFIG_IOMMU_INTEL since c5a5dc4cbbf4 > ("iommu/vt-d: Don't switch off swiotlb if bounce page is used") there's > a dependency on CONFIG_SWIOTLB, which was not necessarily active before. > > The init code for swiotlb in 'pci_swiotlb_detect_4gb()' compares > something against MAX_DMA32_PFN to decide if it should be active. > However that define suffers from an arithmetic overflow since > 1b7e03ef7570 ("x86, NUMA: Enable emulation on 32bit too") when it was > first made visible to x86_32. > > The effect is at boot time 64 MiB (default size) were allocated for > bounce buffers now, which is a noticeable amount of memory on small > systems. We noticed this effect on the fli4l Linux distribution when > migrating from kernel v4.19 (LTS) to v5.4 (LTS) on boards like pcengines > ALIX 2D3 with 256 MiB memory for example: > > Linux version 5.4.22 (buildroot@buildroot) (gcc version 7.3.0 (Buildroot 2018.02.8)) #1 SMP Mon Nov 26 23:40:00 CET 2018 > … > Memory: 183484K/261756K available (4594K kernel code, 393K rwdata, 1660K rodata, 536K init, 456K bss , 78272K reserved, 0K cma-reserved, 0K highmem) > … > PCI-DMA: Using software bounce buffering for IO (SWIOTLB) > software IO TLB: mapped [mem 0x0bb78000-0x0fb78000] (64MB) > > The initial analysis and the suggested fix was done by user 'sourcejedi' > at stackoverflow and explicitly marked as GPLv2 for inclusion in the > Linux kernel: > > https://unix.stackexchange.com/a/520525/50007 > > Fixes: https://web.nettworks.org/bugs/browse/FFL-2560 > Fixes: https://unix.stackexchange.com/q/520065/50007 > Suggested-by: Alan Jenkins <alan.christopher.jenkins@gmail.com> > Signed-off-by: Alexander Dahl <post@lespocky.de> > --- > We tested this in qemu and on real hardware with fli4l on top of v5.4, > v5.5, and v5.6-rc kernels, but only as far as the reserved memory goes. > The patch itself is based on v5.6-rc3 (IIRC). > > A quick grep over the kernel code showed me this define MAX_DMA32_PFN is > used in other places as well. I would appreciate feedback on this, > because I can not oversee all side effects this might have?! > > Thanks again to Alan who proposed the fix, and for his permission to > send it upstream. > > Greets > Alex > --- > arch/x86/include/asm/dma.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/include/asm/dma.h b/arch/x86/include/asm/dma.h > index 00f7cf45e699..e25514eca8d6 100644 > --- a/arch/x86/include/asm/dma.h > +++ b/arch/x86/include/asm/dma.h > @@ -74,7 +74,7 @@ > #define MAX_DMA_PFN ((16UL * 1024 * 1024) >> PAGE_SHIFT) > > /* 4GB broken PCI/AGP hardware bus master zone */ > -#define MAX_DMA32_PFN ((4UL * 1024 * 1024 * 1024) >> PAGE_SHIFT) > +#define MAX_DMA32_PFN (4UL * ((1024 * 1024 * 1024) >> PAGE_SHIFT)) FWIW, wouldn't s/UL/ULL/ in the original expression suffice? Failing that, rather than awkward parenthesis trickery it might be clearer to just copy the one from arch/mips/include/asm/dma.h. Robin. > > #ifdef CONFIG_X86_32 > /* The maximum address that we can perform a DMA transfer to on this platform */ > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] dma: Fix max PFN arithmetic overflow on 32 bit systems 2020-03-19 13:50 ` Robin Murphy @ 2020-03-19 15:31 ` Alexander Dahl 2020-03-21 18:28 ` [PATCH v2] " Alexander Dahl 0 siblings, 1 reply; 7+ messages in thread From: Alexander Dahl @ 2020-03-19 15:31 UTC (permalink / raw) To: Robin Murphy Cc: x86, iommu, linux-kernel, Alan Jenkins, Alexander Dahl, Borislav Petkov, H . Peter Anvin, Thomas Gleixner, Ingo Molnar [-- Attachment #1.1: Type: text/plain, Size: 1634 bytes --] Hello Robin, On Thu, Mar 19, 2020 at 01:50:56PM +0000, Robin Murphy wrote: > On 2020-03-02 6:16 pm, Alexander Dahl wrote: > > --- > > arch/x86/include/asm/dma.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/x86/include/asm/dma.h b/arch/x86/include/asm/dma.h > > index 00f7cf45e699..e25514eca8d6 100644 > > --- a/arch/x86/include/asm/dma.h > > +++ b/arch/x86/include/asm/dma.h > > @@ -74,7 +74,7 @@ > > #define MAX_DMA_PFN ((16UL * 1024 * 1024) >> PAGE_SHIFT) > > /* 4GB broken PCI/AGP hardware bus master zone */ > > -#define MAX_DMA32_PFN ((4UL * 1024 * 1024 * 1024) >> PAGE_SHIFT) > > +#define MAX_DMA32_PFN (4UL * ((1024 * 1024 * 1024) >> PAGE_SHIFT)) > > FWIW, wouldn't s/UL/ULL/ in the original expression suffice? Failing that, > rather than awkward parenthesis trickery it might be clearer to just copy > the one from arch/mips/include/asm/dma.h. Both of your suggestions yield the correct result, and at least for me both look easier to understand than what Alan proposed in the first place. I would opt for the variant which is already in arch/mips, because it avoids 64 bit calculation, is most obvious in intent in my eyes, and we have the same calculation twice then instead of two variants. Thanks for your review, I'll send a v2. :-) Greets Alex -- /"\ ASCII RIBBON | »With the first link, the chain is forged. The first \ / CAMPAIGN | speech censured, the first thought forbidden, the X AGAINST | first freedom denied, chains us all irrevocably.« / \ HTML MAIL | (Jean-Luc Picard, quoting Judge Aaron Satie) [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 156 bytes --] _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH v2] dma: Fix max PFN arithmetic overflow on 32 bit systems 2020-03-19 15:31 ` Alexander Dahl @ 2020-03-21 18:28 ` Alexander Dahl 2020-04-15 14:35 ` Alexander Dahl 0 siblings, 1 reply; 7+ messages in thread From: Alexander Dahl @ 2020-03-21 18:28 UTC (permalink / raw) To: x86 Cc: Alexander Dahl, iommu, linux-kernel, Alan Jenkins, Ingo Molnar, Borislav Petkov, H . Peter Anvin, Thomas Gleixner, Robin Murphy For ARCH=x86 (32 bit) when you set CONFIG_IOMMU_INTEL since c5a5dc4cbbf4 ("iommu/vt-d: Don't switch off swiotlb if bounce page is used") there's a dependency on CONFIG_SWIOTLB, which was not necessarily active before. The init code for swiotlb in 'pci_swiotlb_detect_4gb()' compares something against MAX_DMA32_PFN to decide if it should be active. However that define suffers from an arithmetic overflow since 1b7e03ef7570 ("x86, NUMA: Enable emulation on 32bit too") when it was first made visible to x86_32. The effect is at boot time 64 MiB (default size) were allocated for bounce buffers now, which is a noticeable amount of memory on small systems. We noticed this effect on the fli4l Linux distribution when migrating from kernel v4.19 (LTS) to v5.4 (LTS) on boards like pcengines ALIX 2D3 with 256 MiB memory for example: Linux version 5.4.22 (buildroot@buildroot) (gcc version 7.3.0 (Buildroot 2018.02.8)) #1 SMP Mon Nov 26 23:40:00 CET 2018 … Memory: 183484K/261756K available (4594K kernel code, 393K rwdata, 1660K rodata, 536K init, 456K bss , 78272K reserved, 0K cma-reserved, 0K highmem) … PCI-DMA: Using software bounce buffering for IO (SWIOTLB) software IO TLB: mapped [mem 0x0bb78000-0x0fb78000] (64MB) The initial analysis and the suggested fix was done by user 'sourcejedi' at stackoverflow and explicitly marked as GPLv2 for inclusion in the Linux kernel: https://unix.stackexchange.com/a/520525/50007 The actual calculation however is the same as for arch/mips now as suggested by Robin Murphy. Fixes: https://web.nettworks.org/bugs/browse/FFL-2560 Fixes: https://unix.stackexchange.com/q/520065/50007 Reported-by: Alan Jenkins <alan.christopher.jenkins@gmail.com> Suggested-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Alexander Dahl <post@lespocky.de> --- Notes: v1 -> v2: - use the same calculation as with arch/mips (Robin Murphy) arch/x86/include/asm/dma.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/dma.h b/arch/x86/include/asm/dma.h index 00f7cf45e699..8e95aa4b0d17 100644 --- a/arch/x86/include/asm/dma.h +++ b/arch/x86/include/asm/dma.h @@ -74,7 +74,7 @@ #define MAX_DMA_PFN ((16UL * 1024 * 1024) >> PAGE_SHIFT) /* 4GB broken PCI/AGP hardware bus master zone */ -#define MAX_DMA32_PFN ((4UL * 1024 * 1024 * 1024) >> PAGE_SHIFT) +#define MAX_DMA32_PFN (1UL << (32 - PAGE_SHIFT)) #ifdef CONFIG_X86_32 /* The maximum address that we can perform a DMA transfer to on this platform */ -- 2.20.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH v2] dma: Fix max PFN arithmetic overflow on 32 bit systems 2020-03-21 18:28 ` [PATCH v2] " Alexander Dahl @ 2020-04-15 14:35 ` Alexander Dahl 2020-05-05 9:38 ` Alexander Dahl 0 siblings, 1 reply; 7+ messages in thread From: Alexander Dahl @ 2020-04-15 14:35 UTC (permalink / raw) To: x86 Cc: Alexander Dahl, iommu, linux-kernel, Alan Jenkins, Ingo Molnar, Borislav Petkov, H . Peter Anvin, Thomas Gleixner, Robin Murphy, Florian Wolters [-- Attachment #1.1: Type: text/plain, Size: 3516 bytes --] Hello, now after v5.7-rc1 is out, I would kindly ask, if anyone had time to review this one line patch? Is anything wrong with that fix? (I added the current fli4l kernel package maintainer Florian to Cc to let him know I'm still having an eye on this.) Greets Alex On Sat, Mar 21, 2020 at 07:28:23PM +0100, Alexander Dahl wrote: > For ARCH=x86 (32 bit) when you set CONFIG_IOMMU_INTEL since c5a5dc4cbbf4 > ("iommu/vt-d: Don't switch off swiotlb if bounce page is used") there's > a dependency on CONFIG_SWIOTLB, which was not necessarily active before. > > The init code for swiotlb in 'pci_swiotlb_detect_4gb()' compares > something against MAX_DMA32_PFN to decide if it should be active. > However that define suffers from an arithmetic overflow since > 1b7e03ef7570 ("x86, NUMA: Enable emulation on 32bit too") when it was > first made visible to x86_32. > > The effect is at boot time 64 MiB (default size) were allocated for > bounce buffers now, which is a noticeable amount of memory on small > systems. We noticed this effect on the fli4l Linux distribution when > migrating from kernel v4.19 (LTS) to v5.4 (LTS) on boards like pcengines > ALIX 2D3 with 256 MiB memory for example: > > Linux version 5.4.22 (buildroot@buildroot) (gcc version 7.3.0 (Buildroot 2018.02.8)) #1 SMP Mon Nov 26 23:40:00 CET 2018 > … > Memory: 183484K/261756K available (4594K kernel code, 393K rwdata, 1660K rodata, 536K init, 456K bss , 78272K reserved, 0K cma-reserved, 0K highmem) > … > PCI-DMA: Using software bounce buffering for IO (SWIOTLB) > software IO TLB: mapped [mem 0x0bb78000-0x0fb78000] (64MB) > > The initial analysis and the suggested fix was done by user 'sourcejedi' > at stackoverflow and explicitly marked as GPLv2 for inclusion in the > Linux kernel: > > https://unix.stackexchange.com/a/520525/50007 > > The actual calculation however is the same as for arch/mips now as > suggested by Robin Murphy. > > Fixes: https://web.nettworks.org/bugs/browse/FFL-2560 > Fixes: https://unix.stackexchange.com/q/520065/50007 > Reported-by: Alan Jenkins <alan.christopher.jenkins@gmail.com> > Suggested-by: Robin Murphy <robin.murphy@arm.com> > Signed-off-by: Alexander Dahl <post@lespocky.de> > --- > > Notes: > v1 -> v2: > - use the same calculation as with arch/mips (Robin Murphy) > > arch/x86/include/asm/dma.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/include/asm/dma.h b/arch/x86/include/asm/dma.h > index 00f7cf45e699..8e95aa4b0d17 100644 > --- a/arch/x86/include/asm/dma.h > +++ b/arch/x86/include/asm/dma.h > @@ -74,7 +74,7 @@ > #define MAX_DMA_PFN ((16UL * 1024 * 1024) >> PAGE_SHIFT) > > /* 4GB broken PCI/AGP hardware bus master zone */ > -#define MAX_DMA32_PFN ((4UL * 1024 * 1024 * 1024) >> PAGE_SHIFT) > +#define MAX_DMA32_PFN (1UL << (32 - PAGE_SHIFT)) > > #ifdef CONFIG_X86_32 > /* The maximum address that we can perform a DMA transfer to on this platform */ > -- > 2.20.1 > > _______________________________________________ > iommu mailing list > iommu@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu -- /"\ ASCII RIBBON | »With the first link, the chain is forged. The first \ / CAMPAIGN | speech censured, the first thought forbidden, the X AGAINST | first freedom denied, chains us all irrevocably.« / \ HTML MAIL | (Jean-Luc Picard, quoting Judge Aaron Satie) [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 156 bytes --] _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] dma: Fix max PFN arithmetic overflow on 32 bit systems 2020-04-15 14:35 ` Alexander Dahl @ 2020-05-05 9:38 ` Alexander Dahl 0 siblings, 0 replies; 7+ messages in thread From: Alexander Dahl @ 2020-05-05 9:38 UTC (permalink / raw) To: x86, iommu, linux-kernel, Alan Jenkins, Ingo Molnar, Borislav Petkov, H . Peter Anvin, Thomas Gleixner, Robin Murphy, Florian Wolters [-- Attachment #1.1: Type: text/plain, Size: 3737 bytes --] Hei hei, I would like to kindly ask about the status of this patch. On Wed, Apr 15, 2020 at 04:35:21PM +0200, Alexander Dahl wrote: > now after v5.7-rc1 is out, I would kindly ask, if anyone had time to > review this one line patch? Is anything wrong with that fix? Did it maybe not reach the right maintainers? I used scripts/get_maintainer.pl to get my recipient list. > (I added the current fli4l kernel package maintainer Florian to Cc to > let him know I'm still having an eye on this.) > > Greets > Alex > > On Sat, Mar 21, 2020 at 07:28:23PM +0100, Alexander Dahl wrote: > > For ARCH=x86 (32 bit) when you set CONFIG_IOMMU_INTEL since c5a5dc4cbbf4 > > ("iommu/vt-d: Don't switch off swiotlb if bounce page is used") there's > > a dependency on CONFIG_SWIOTLB, which was not necessarily active before. > > > > The init code for swiotlb in 'pci_swiotlb_detect_4gb()' compares > > something against MAX_DMA32_PFN to decide if it should be active. > > However that define suffers from an arithmetic overflow since > > 1b7e03ef7570 ("x86, NUMA: Enable emulation on 32bit too") when it was > > first made visible to x86_32. > > > > The effect is at boot time 64 MiB (default size) were allocated for > > bounce buffers now, which is a noticeable amount of memory on small > > systems. We noticed this effect on the fli4l Linux distribution when > > migrating from kernel v4.19 (LTS) to v5.4 (LTS) on boards like pcengines > > ALIX 2D3 with 256 MiB memory for example: > > > > Linux version 5.4.22 (buildroot@buildroot) (gcc version 7.3.0 (Buildroot 2018.02.8)) #1 SMP Mon Nov 26 23:40:00 CET 2018 > > … > > Memory: 183484K/261756K available (4594K kernel code, 393K rwdata, 1660K rodata, 536K init, 456K bss , 78272K reserved, 0K cma-reserved, 0K highmem) > > … > > PCI-DMA: Using software bounce buffering for IO (SWIOTLB) > > software IO TLB: mapped [mem 0x0bb78000-0x0fb78000] (64MB) > > > > The initial analysis and the suggested fix was done by user 'sourcejedi' > > at stackoverflow and explicitly marked as GPLv2 for inclusion in the > > Linux kernel: > > > > https://unix.stackexchange.com/a/520525/50007 > > > > The actual calculation however is the same as for arch/mips now as > > suggested by Robin Murphy. > > > > Fixes: https://web.nettworks.org/bugs/browse/FFL-2560 > > Fixes: https://unix.stackexchange.com/q/520065/50007 > > Reported-by: Alan Jenkins <alan.christopher.jenkins@gmail.com> > > Suggested-by: Robin Murphy <robin.murphy@arm.com> > > Signed-off-by: Alexander Dahl <post@lespocky.de> > > --- > > > > Notes: > > v1 -> v2: > > - use the same calculation as with arch/mips (Robin Murphy) > > > > arch/x86/include/asm/dma.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/x86/include/asm/dma.h b/arch/x86/include/asm/dma.h > > index 00f7cf45e699..8e95aa4b0d17 100644 > > --- a/arch/x86/include/asm/dma.h > > +++ b/arch/x86/include/asm/dma.h > > @@ -74,7 +74,7 @@ > > #define MAX_DMA_PFN ((16UL * 1024 * 1024) >> PAGE_SHIFT) > > > > /* 4GB broken PCI/AGP hardware bus master zone */ > > -#define MAX_DMA32_PFN ((4UL * 1024 * 1024 * 1024) >> PAGE_SHIFT) > > +#define MAX_DMA32_PFN (1UL << (32 - PAGE_SHIFT)) > > > > #ifdef CONFIG_X86_32 > > /* The maximum address that we can perform a DMA transfer to on this platform */ > > -- > > 2.20.1 Greets Alex -- /"\ ASCII RIBBON | »With the first link, the chain is forged. The first \ / CAMPAIGN | speech censured, the first thought forbidden, the X AGAINST | first freedom denied, chains us all irrevocably.« / \ HTML MAIL | (Jean-Luc Picard, quoting Judge Aaron Satie) [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 156 bytes --] _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-05-05 9:39 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-02 18:16 [PATCH] dma: Fix max PFN arithmetic overflow on 32 bit systems Alexander Dahl 2020-03-18 9:41 ` Alexander Dahl 2020-03-19 13:50 ` Robin Murphy 2020-03-19 15:31 ` Alexander Dahl 2020-03-21 18:28 ` [PATCH v2] " Alexander Dahl 2020-04-15 14:35 ` Alexander Dahl 2020-05-05 9:38 ` Alexander Dahl
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).