* [PATCH v2] ARM: Fix MAX_DMA_ADDRESS overflow
@ 2022-07-06 16:46 ` Florian Fainelli
0 siblings, 0 replies; 10+ messages in thread
From: Florian Fainelli @ 2022-07-06 16:46 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Florian Fainelli, Russell King, Andrew Morton, Grygorii Strashko,
open list, ssantosh, ardb, linus.walleij, geert+renesas
Commit 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
added a check to determine whether arm_dma_zone_size is exceeding the
amount of kernel virtual address space available between the upper 4GB
virtual address limit and PAGE_OFFSET in order to provide a suitable
definition of MAX_DMA_ADDRESS that should fit within the 32-bit virtual
address space. The quantity used for comparison was off by a missing
trailing 0, leading to MAX_DMA_ADDRESS to be overflowing a 32-bit
quantity.
This was caught with the bcm2711 platforms which defines a dma_zone_size
of 1GB, and using a PAGE_OFFSET of 0xc000_0000 (CONFIG_VMSPLIT_3G) with
CONFIG_DEBUG_VIRTUAL enabled would lead to MAX_DMA_ADDRESS being
0x1_0000_0000 which overflows the unsigned long type used throughout
__pa() and __virt_addr_valid(). Because the virtual address passed to
__virt_addr_valid() would now be 0, the function would loudly warn, thus
making the platform unable to boot properly.
Fixes: 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Changes in v2:
- simplify the patch and drop the first patch that attempted to fix an
off by one in the calculation.
arch/arm/include/asm/dma.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/dma.h b/arch/arm/include/asm/dma.h
index a81dda65c576..1ffa75beb709 100644
--- a/arch/arm/include/asm/dma.h
+++ b/arch/arm/include/asm/dma.h
@@ -10,7 +10,7 @@
#else
#define MAX_DMA_ADDRESS ({ \
extern phys_addr_t arm_dma_zone_size; \
- arm_dma_zone_size && arm_dma_zone_size < (0x10000000 - PAGE_OFFSET) ? \
+ arm_dma_zone_size && arm_dma_zone_size < (0x100000000 - PAGE_OFFSET) ? \
(PAGE_OFFSET + arm_dma_zone_size) : 0xffffffffUL; })
#endif
--
2.25.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH v2] ARM: Fix MAX_DMA_ADDRESS overflow
@ 2022-07-06 16:46 ` Florian Fainelli
0 siblings, 0 replies; 10+ messages in thread
From: Florian Fainelli @ 2022-07-06 16:46 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Florian Fainelli, Russell King, Andrew Morton, Grygorii Strashko,
open list, ssantosh, ardb, linus.walleij, geert+renesas
Commit 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
added a check to determine whether arm_dma_zone_size is exceeding the
amount of kernel virtual address space available between the upper 4GB
virtual address limit and PAGE_OFFSET in order to provide a suitable
definition of MAX_DMA_ADDRESS that should fit within the 32-bit virtual
address space. The quantity used for comparison was off by a missing
trailing 0, leading to MAX_DMA_ADDRESS to be overflowing a 32-bit
quantity.
This was caught with the bcm2711 platforms which defines a dma_zone_size
of 1GB, and using a PAGE_OFFSET of 0xc000_0000 (CONFIG_VMSPLIT_3G) with
CONFIG_DEBUG_VIRTUAL enabled would lead to MAX_DMA_ADDRESS being
0x1_0000_0000 which overflows the unsigned long type used throughout
__pa() and __virt_addr_valid(). Because the virtual address passed to
__virt_addr_valid() would now be 0, the function would loudly warn, thus
making the platform unable to boot properly.
Fixes: 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Changes in v2:
- simplify the patch and drop the first patch that attempted to fix an
off by one in the calculation.
arch/arm/include/asm/dma.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/dma.h b/arch/arm/include/asm/dma.h
index a81dda65c576..1ffa75beb709 100644
--- a/arch/arm/include/asm/dma.h
+++ b/arch/arm/include/asm/dma.h
@@ -10,7 +10,7 @@
#else
#define MAX_DMA_ADDRESS ({ \
extern phys_addr_t arm_dma_zone_size; \
- arm_dma_zone_size && arm_dma_zone_size < (0x10000000 - PAGE_OFFSET) ? \
+ arm_dma_zone_size && arm_dma_zone_size < (0x100000000 - PAGE_OFFSET) ? \
(PAGE_OFFSET + arm_dma_zone_size) : 0xffffffffUL; })
#endif
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v2] ARM: Fix MAX_DMA_ADDRESS overflow
2022-07-06 16:46 ` Florian Fainelli
@ 2022-07-06 19:44 ` Geert Uytterhoeven
-1 siblings, 0 replies; 10+ messages in thread
From: Geert Uytterhoeven @ 2022-07-06 19:44 UTC (permalink / raw)
To: Florian Fainelli
Cc: Linux ARM, Russell King, Andrew Morton, Grygorii Strashko,
open list, Santosh Shilimkar, Ard Biesheuvel, Linus Walleij,
Geert Uytterhoeven
Hi Florian,
On Wed, Jul 6, 2022 at 6:46 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> Commit 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
> added a check to determine whether arm_dma_zone_size is exceeding the
> amount of kernel virtual address space available between the upper 4GB
> virtual address limit and PAGE_OFFSET in order to provide a suitable
> definition of MAX_DMA_ADDRESS that should fit within the 32-bit virtual
> address space. The quantity used for comparison was off by a missing
> trailing 0, leading to MAX_DMA_ADDRESS to be overflowing a 32-bit
> quantity.
>
> This was caught with the bcm2711 platforms which defines a dma_zone_size
> of 1GB, and using a PAGE_OFFSET of 0xc000_0000 (CONFIG_VMSPLIT_3G) with
> CONFIG_DEBUG_VIRTUAL enabled would lead to MAX_DMA_ADDRESS being
> 0x1_0000_0000 which overflows the unsigned long type used throughout
> __pa() and __virt_addr_valid(). Because the virtual address passed to
> __virt_addr_valid() would now be 0, the function would loudly warn, thus
> making the platform unable to boot properly.
>
> Fixes: 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> Changes in v2:
>
> - simplify the patch and drop the first patch that attempted to fix an
> off by one in the calculation.
Thanks for the update!
> --- a/arch/arm/include/asm/dma.h
> +++ b/arch/arm/include/asm/dma.h
> @@ -10,7 +10,7 @@
> #else
> #define MAX_DMA_ADDRESS ({ \
> extern phys_addr_t arm_dma_zone_size; \
> - arm_dma_zone_size && arm_dma_zone_size < (0x10000000 - PAGE_OFFSET) ? \
^^^^^^^^^^
0x10000000ULL, as the constant doesn't fit in 32-bit.
However, both gcc (9.4.0) and sparse don't seem to complain about
the missing suffix (anymore?).
> + arm_dma_zone_size && arm_dma_zone_size < (0x100000000 - PAGE_OFFSET) ? \
> (PAGE_OFFSET + arm_dma_zone_size) : 0xffffffffUL; })
> #endif
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] ARM: Fix MAX_DMA_ADDRESS overflow
@ 2022-07-06 19:44 ` Geert Uytterhoeven
0 siblings, 0 replies; 10+ messages in thread
From: Geert Uytterhoeven @ 2022-07-06 19:44 UTC (permalink / raw)
To: Florian Fainelli
Cc: Linux ARM, Russell King, Andrew Morton, Grygorii Strashko,
open list, Santosh Shilimkar, Ard Biesheuvel, Linus Walleij,
Geert Uytterhoeven
Hi Florian,
On Wed, Jul 6, 2022 at 6:46 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> Commit 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
> added a check to determine whether arm_dma_zone_size is exceeding the
> amount of kernel virtual address space available between the upper 4GB
> virtual address limit and PAGE_OFFSET in order to provide a suitable
> definition of MAX_DMA_ADDRESS that should fit within the 32-bit virtual
> address space. The quantity used for comparison was off by a missing
> trailing 0, leading to MAX_DMA_ADDRESS to be overflowing a 32-bit
> quantity.
>
> This was caught with the bcm2711 platforms which defines a dma_zone_size
> of 1GB, and using a PAGE_OFFSET of 0xc000_0000 (CONFIG_VMSPLIT_3G) with
> CONFIG_DEBUG_VIRTUAL enabled would lead to MAX_DMA_ADDRESS being
> 0x1_0000_0000 which overflows the unsigned long type used throughout
> __pa() and __virt_addr_valid(). Because the virtual address passed to
> __virt_addr_valid() would now be 0, the function would loudly warn, thus
> making the platform unable to boot properly.
>
> Fixes: 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> Changes in v2:
>
> - simplify the patch and drop the first patch that attempted to fix an
> off by one in the calculation.
Thanks for the update!
> --- a/arch/arm/include/asm/dma.h
> +++ b/arch/arm/include/asm/dma.h
> @@ -10,7 +10,7 @@
> #else
> #define MAX_DMA_ADDRESS ({ \
> extern phys_addr_t arm_dma_zone_size; \
> - arm_dma_zone_size && arm_dma_zone_size < (0x10000000 - PAGE_OFFSET) ? \
^^^^^^^^^^
0x10000000ULL, as the constant doesn't fit in 32-bit.
However, both gcc (9.4.0) and sparse don't seem to complain about
the missing suffix (anymore?).
> + arm_dma_zone_size && arm_dma_zone_size < (0x100000000 - PAGE_OFFSET) ? \
> (PAGE_OFFSET + arm_dma_zone_size) : 0xffffffffUL; })
> #endif
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] ARM: Fix MAX_DMA_ADDRESS overflow
2022-07-06 19:44 ` Geert Uytterhoeven
@ 2022-07-06 19:46 ` Geert Uytterhoeven
-1 siblings, 0 replies; 10+ messages in thread
From: Geert Uytterhoeven @ 2022-07-06 19:46 UTC (permalink / raw)
To: Florian Fainelli
Cc: Linux ARM, Russell King, Andrew Morton, Grygorii Strashko,
open list, Santosh Shilimkar, Ard Biesheuvel, Linus Walleij,
Geert Uytterhoeven
On Wed, Jul 6, 2022 at 9:44 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Wed, Jul 6, 2022 at 6:46 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> > Commit 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
> > added a check to determine whether arm_dma_zone_size is exceeding the
> > amount of kernel virtual address space available between the upper 4GB
> > virtual address limit and PAGE_OFFSET in order to provide a suitable
> > definition of MAX_DMA_ADDRESS that should fit within the 32-bit virtual
> > address space. The quantity used for comparison was off by a missing
> > trailing 0, leading to MAX_DMA_ADDRESS to be overflowing a 32-bit
> > quantity.
> >
> > This was caught with the bcm2711 platforms which defines a dma_zone_size
> > of 1GB, and using a PAGE_OFFSET of 0xc000_0000 (CONFIG_VMSPLIT_3G) with
> > CONFIG_DEBUG_VIRTUAL enabled would lead to MAX_DMA_ADDRESS being
> > 0x1_0000_0000 which overflows the unsigned long type used throughout
> > __pa() and __virt_addr_valid(). Because the virtual address passed to
> > __virt_addr_valid() would now be 0, the function would loudly warn, thus
> > making the platform unable to boot properly.
> >
> > Fixes: 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
> > Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> > ---
> > Changes in v2:
> >
> > - simplify the patch and drop the first patch that attempted to fix an
> > off by one in the calculation.
>
> Thanks for the update!
>
> > --- a/arch/arm/include/asm/dma.h
> > +++ b/arch/arm/include/asm/dma.h
> > @@ -10,7 +10,7 @@
> > #else
> > #define MAX_DMA_ADDRESS ({ \
> > extern phys_addr_t arm_dma_zone_size; \
> > - arm_dma_zone_size && arm_dma_zone_size < (0x10000000 - PAGE_OFFSET) ? \
> ^^^^^^^^^^
> 0x10000000ULL, as the constant doesn't fit in 32-bit.
> However, both gcc (9.4.0) and sparse don't seem to complain about
> the missing suffix (anymore?).
>
> > + arm_dma_zone_size && arm_dma_zone_size < (0x100000000 - PAGE_OFFSET) ? \
Obviously my comment applies to the _new_ line, not to the removed
line...
> > (PAGE_OFFSET + arm_dma_zone_size) : 0xffffffffUL; })
> > #endif
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] ARM: Fix MAX_DMA_ADDRESS overflow
@ 2022-07-06 19:46 ` Geert Uytterhoeven
0 siblings, 0 replies; 10+ messages in thread
From: Geert Uytterhoeven @ 2022-07-06 19:46 UTC (permalink / raw)
To: Florian Fainelli
Cc: Linux ARM, Russell King, Andrew Morton, Grygorii Strashko,
open list, Santosh Shilimkar, Ard Biesheuvel, Linus Walleij,
Geert Uytterhoeven
On Wed, Jul 6, 2022 at 9:44 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Wed, Jul 6, 2022 at 6:46 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> > Commit 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
> > added a check to determine whether arm_dma_zone_size is exceeding the
> > amount of kernel virtual address space available between the upper 4GB
> > virtual address limit and PAGE_OFFSET in order to provide a suitable
> > definition of MAX_DMA_ADDRESS that should fit within the 32-bit virtual
> > address space. The quantity used for comparison was off by a missing
> > trailing 0, leading to MAX_DMA_ADDRESS to be overflowing a 32-bit
> > quantity.
> >
> > This was caught with the bcm2711 platforms which defines a dma_zone_size
> > of 1GB, and using a PAGE_OFFSET of 0xc000_0000 (CONFIG_VMSPLIT_3G) with
> > CONFIG_DEBUG_VIRTUAL enabled would lead to MAX_DMA_ADDRESS being
> > 0x1_0000_0000 which overflows the unsigned long type used throughout
> > __pa() and __virt_addr_valid(). Because the virtual address passed to
> > __virt_addr_valid() would now be 0, the function would loudly warn, thus
> > making the platform unable to boot properly.
> >
> > Fixes: 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
> > Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> > ---
> > Changes in v2:
> >
> > - simplify the patch and drop the first patch that attempted to fix an
> > off by one in the calculation.
>
> Thanks for the update!
>
> > --- a/arch/arm/include/asm/dma.h
> > +++ b/arch/arm/include/asm/dma.h
> > @@ -10,7 +10,7 @@
> > #else
> > #define MAX_DMA_ADDRESS ({ \
> > extern phys_addr_t arm_dma_zone_size; \
> > - arm_dma_zone_size && arm_dma_zone_size < (0x10000000 - PAGE_OFFSET) ? \
> ^^^^^^^^^^
> 0x10000000ULL, as the constant doesn't fit in 32-bit.
> However, both gcc (9.4.0) and sparse don't seem to complain about
> the missing suffix (anymore?).
>
> > + arm_dma_zone_size && arm_dma_zone_size < (0x100000000 - PAGE_OFFSET) ? \
Obviously my comment applies to the _new_ line, not to the removed
line...
> > (PAGE_OFFSET + arm_dma_zone_size) : 0xffffffffUL; })
> > #endif
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] ARM: Fix MAX_DMA_ADDRESS overflow
2022-07-06 19:44 ` Geert Uytterhoeven
@ 2022-07-06 20:26 ` Florian Fainelli
-1 siblings, 0 replies; 10+ messages in thread
From: Florian Fainelli @ 2022-07-06 20:26 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux ARM, Russell King, Andrew Morton, Grygorii Strashko,
open list, Santosh Shilimkar, Ard Biesheuvel, Linus Walleij,
Geert Uytterhoeven
On 7/6/22 12:44, Geert Uytterhoeven wrote:
> Hi Florian,
>
> On Wed, Jul 6, 2022 at 6:46 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>> Commit 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
>> added a check to determine whether arm_dma_zone_size is exceeding the
>> amount of kernel virtual address space available between the upper 4GB
>> virtual address limit and PAGE_OFFSET in order to provide a suitable
>> definition of MAX_DMA_ADDRESS that should fit within the 32-bit virtual
>> address space. The quantity used for comparison was off by a missing
>> trailing 0, leading to MAX_DMA_ADDRESS to be overflowing a 32-bit
>> quantity.
>>
>> This was caught with the bcm2711 platforms which defines a dma_zone_size
>> of 1GB, and using a PAGE_OFFSET of 0xc000_0000 (CONFIG_VMSPLIT_3G) with
>> CONFIG_DEBUG_VIRTUAL enabled would lead to MAX_DMA_ADDRESS being
>> 0x1_0000_0000 which overflows the unsigned long type used throughout
>> __pa() and __virt_addr_valid(). Because the virtual address passed to
>> __virt_addr_valid() would now be 0, the function would loudly warn, thus
>> making the platform unable to boot properly.
>>
>> Fixes: 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> Changes in v2:
>>
>> - simplify the patch and drop the first patch that attempted to fix an
>> off by one in the calculation.
>
> Thanks for the update!
>
>> --- a/arch/arm/include/asm/dma.h
>> +++ b/arch/arm/include/asm/dma.h
>> @@ -10,7 +10,7 @@
>> #else
>> #define MAX_DMA_ADDRESS ({ \
>> extern phys_addr_t arm_dma_zone_size; \
>> - arm_dma_zone_size && arm_dma_zone_size < (0x10000000 - PAGE_OFFSET) ? \
> ^^^^^^^^^^
> 0x10000000ULL, as the constant doesn't fit in 32-bit.
> However, both gcc (9.4.0) and sparse don't seem to complain about
> the missing suffix (anymore?).
Thanks, I will the ULL suffix in v3.
--
Florian
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] ARM: Fix MAX_DMA_ADDRESS overflow
@ 2022-07-06 20:26 ` Florian Fainelli
0 siblings, 0 replies; 10+ messages in thread
From: Florian Fainelli @ 2022-07-06 20:26 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux ARM, Russell King, Andrew Morton, Grygorii Strashko,
open list, Santosh Shilimkar, Ard Biesheuvel, Linus Walleij,
Geert Uytterhoeven
On 7/6/22 12:44, Geert Uytterhoeven wrote:
> Hi Florian,
>
> On Wed, Jul 6, 2022 at 6:46 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>> Commit 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
>> added a check to determine whether arm_dma_zone_size is exceeding the
>> amount of kernel virtual address space available between the upper 4GB
>> virtual address limit and PAGE_OFFSET in order to provide a suitable
>> definition of MAX_DMA_ADDRESS that should fit within the 32-bit virtual
>> address space. The quantity used for comparison was off by a missing
>> trailing 0, leading to MAX_DMA_ADDRESS to be overflowing a 32-bit
>> quantity.
>>
>> This was caught with the bcm2711 platforms which defines a dma_zone_size
>> of 1GB, and using a PAGE_OFFSET of 0xc000_0000 (CONFIG_VMSPLIT_3G) with
>> CONFIG_DEBUG_VIRTUAL enabled would lead to MAX_DMA_ADDRESS being
>> 0x1_0000_0000 which overflows the unsigned long type used throughout
>> __pa() and __virt_addr_valid(). Because the virtual address passed to
>> __virt_addr_valid() would now be 0, the function would loudly warn, thus
>> making the platform unable to boot properly.
>>
>> Fixes: 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> Changes in v2:
>>
>> - simplify the patch and drop the first patch that attempted to fix an
>> off by one in the calculation.
>
> Thanks for the update!
>
>> --- a/arch/arm/include/asm/dma.h
>> +++ b/arch/arm/include/asm/dma.h
>> @@ -10,7 +10,7 @@
>> #else
>> #define MAX_DMA_ADDRESS ({ \
>> extern phys_addr_t arm_dma_zone_size; \
>> - arm_dma_zone_size && arm_dma_zone_size < (0x10000000 - PAGE_OFFSET) ? \
> ^^^^^^^^^^
> 0x10000000ULL, as the constant doesn't fit in 32-bit.
> However, both gcc (9.4.0) and sparse don't seem to complain about
> the missing suffix (anymore?).
Thanks, I will the ULL suffix in v3.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] ARM: Fix MAX_DMA_ADDRESS overflow
2022-07-06 20:26 ` Florian Fainelli
@ 2022-07-06 21:45 ` Geert Uytterhoeven
-1 siblings, 0 replies; 10+ messages in thread
From: Geert Uytterhoeven @ 2022-07-06 21:45 UTC (permalink / raw)
To: Florian Fainelli
Cc: Linux ARM, Russell King, Andrew Morton, Grygorii Strashko,
open list, Santosh Shilimkar, Ard Biesheuvel, Linus Walleij,
Geert Uytterhoeven
Hi Florian,
On Wed, Jul 6, 2022 at 10:27 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 7/6/22 12:44, Geert Uytterhoeven wrote:
> > On Wed, Jul 6, 2022 at 6:46 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> >> Commit 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
> >> added a check to determine whether arm_dma_zone_size is exceeding the
> >> amount of kernel virtual address space available between the upper 4GB
> >> virtual address limit and PAGE_OFFSET in order to provide a suitable
> >> definition of MAX_DMA_ADDRESS that should fit within the 32-bit virtual
> >> address space. The quantity used for comparison was off by a missing
> >> trailing 0, leading to MAX_DMA_ADDRESS to be overflowing a 32-bit
> >> quantity.
> >>
> >> This was caught with the bcm2711 platforms which defines a dma_zone_size
> >> of 1GB, and using a PAGE_OFFSET of 0xc000_0000 (CONFIG_VMSPLIT_3G) with
> >> CONFIG_DEBUG_VIRTUAL enabled would lead to MAX_DMA_ADDRESS being
> >> 0x1_0000_0000 which overflows the unsigned long type used throughout
> >> __pa() and __virt_addr_valid(). Because the virtual address passed to
> >> __virt_addr_valid() would now be 0, the function would loudly warn, thus
> >> making the platform unable to boot properly.
> >>
> >> Fixes: 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
> >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> >> ---
> >> Changes in v2:
> >>
> >> - simplify the patch and drop the first patch that attempted to fix an
> >> off by one in the calculation.
> >
> > Thanks for the update!
> >
> >> --- a/arch/arm/include/asm/dma.h
> >> +++ b/arch/arm/include/asm/dma.h
> >> @@ -10,7 +10,7 @@
> >> #else
> >> #define MAX_DMA_ADDRESS ({ \
> >> extern phys_addr_t arm_dma_zone_size; \
> >> - arm_dma_zone_size && arm_dma_zone_size < (0x10000000 - PAGE_OFFSET) ? \
> > ^^^^^^^^^^
> > 0x10000000ULL, as the constant doesn't fit in 32-bit.
> > However, both gcc (9.4.0) and sparse don't seem to complain about
> > the missing suffix (anymore?).
>
> Thanks, I will the ULL suffix in v3.
I just remembered the suffix is not needed (but doesn't hurt), because
hexadecimal constants automatically have the right unsigned type.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] ARM: Fix MAX_DMA_ADDRESS overflow
@ 2022-07-06 21:45 ` Geert Uytterhoeven
0 siblings, 0 replies; 10+ messages in thread
From: Geert Uytterhoeven @ 2022-07-06 21:45 UTC (permalink / raw)
To: Florian Fainelli
Cc: Linux ARM, Russell King, Andrew Morton, Grygorii Strashko,
open list, Santosh Shilimkar, Ard Biesheuvel, Linus Walleij,
Geert Uytterhoeven
Hi Florian,
On Wed, Jul 6, 2022 at 10:27 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 7/6/22 12:44, Geert Uytterhoeven wrote:
> > On Wed, Jul 6, 2022 at 6:46 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> >> Commit 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
> >> added a check to determine whether arm_dma_zone_size is exceeding the
> >> amount of kernel virtual address space available between the upper 4GB
> >> virtual address limit and PAGE_OFFSET in order to provide a suitable
> >> definition of MAX_DMA_ADDRESS that should fit within the 32-bit virtual
> >> address space. The quantity used for comparison was off by a missing
> >> trailing 0, leading to MAX_DMA_ADDRESS to be overflowing a 32-bit
> >> quantity.
> >>
> >> This was caught with the bcm2711 platforms which defines a dma_zone_size
> >> of 1GB, and using a PAGE_OFFSET of 0xc000_0000 (CONFIG_VMSPLIT_3G) with
> >> CONFIG_DEBUG_VIRTUAL enabled would lead to MAX_DMA_ADDRESS being
> >> 0x1_0000_0000 which overflows the unsigned long type used throughout
> >> __pa() and __virt_addr_valid(). Because the virtual address passed to
> >> __virt_addr_valid() would now be 0, the function would loudly warn, thus
> >> making the platform unable to boot properly.
> >>
> >> Fixes: 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
> >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> >> ---
> >> Changes in v2:
> >>
> >> - simplify the patch and drop the first patch that attempted to fix an
> >> off by one in the calculation.
> >
> > Thanks for the update!
> >
> >> --- a/arch/arm/include/asm/dma.h
> >> +++ b/arch/arm/include/asm/dma.h
> >> @@ -10,7 +10,7 @@
> >> #else
> >> #define MAX_DMA_ADDRESS ({ \
> >> extern phys_addr_t arm_dma_zone_size; \
> >> - arm_dma_zone_size && arm_dma_zone_size < (0x10000000 - PAGE_OFFSET) ? \
> > ^^^^^^^^^^
> > 0x10000000ULL, as the constant doesn't fit in 32-bit.
> > However, both gcc (9.4.0) and sparse don't seem to complain about
> > the missing suffix (anymore?).
>
> Thanks, I will the ULL suffix in v3.
I just remembered the suffix is not needed (but doesn't hurt), because
hexadecimal constants automatically have the right unsigned type.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2022-07-06 21:46 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-06 16:46 [PATCH v2] ARM: Fix MAX_DMA_ADDRESS overflow Florian Fainelli
2022-07-06 16:46 ` Florian Fainelli
2022-07-06 19:44 ` Geert Uytterhoeven
2022-07-06 19:44 ` Geert Uytterhoeven
2022-07-06 19:46 ` Geert Uytterhoeven
2022-07-06 19:46 ` Geert Uytterhoeven
2022-07-06 20:26 ` Florian Fainelli
2022-07-06 20:26 ` Florian Fainelli
2022-07-06 21:45 ` Geert Uytterhoeven
2022-07-06 21:45 ` Geert Uytterhoeven
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.