MAX_DMA_ADDRESS overflow with non-zero arm_dma_zone_size and VMSPLIT_3G
Florian Fainelli
f.fainelli at gmail.com
Sun Mar 20 20:46:23 PDT 2022
Hi all,
While debugging numerous KASAN splats with CONFIG_DEBUG_VIRTUAL on ARM
32-bit with a Raspberry Pi 4B 4GB, it finally clicked that the problem
is with the use of __virt_to_phys(MAX_DMA_ADDRESS). Since that platform
has CONFIG_ZONE_DMA enabled, we end-up with:
#define MAX_DMA_ADDRESS ({ \
extern phys_addr_t arm_dma_zone_size; \
arm_dma_zone_size && arm_dma_zone_size < (0x10000000 -
PAGE_OFFSET) ? \
(PAGE_OFFSET + arm_dma_zone_size) : 0xffffffffUL; })
and with arch/arm/mach-bcm/bcm2711.c defining a dma_zone_size of SZ_1G
and PAGE_OFFSET = 0xC000_0000 we end up with MAX_DMA_ADDRES of
0x1_0000_0000 which overflows the virtual address size that is
represented with an unsigned long.
All of the virt_to_phys() and related functions either take a pointer
size argument (const volatile void *) or an unsigned long argument and
these are virtual addresses so unable to go over 32-bit anyway.
Since MAX_DMA_ADDRESS is intended to be "This is the maximum virtual
address which can be DMA'd from.", should we make sure that we clamp it
below 32-bit in case it overflows?
The splats can be silenced with this too:
diff --git a/arch/arm/mm/physaddr.c b/arch/arm/mm/physaddr.c
index cf75819e4c13..abf071c7c6e9 100644
--- a/arch/arm/mm/physaddr.c
+++ b/arch/arm/mm/physaddr.c
@@ -29,7 +29,7 @@ static inline bool __virt_addr_valid(unsigned long x)
* actual physical address. Enough code relies on
__pa(MAX_DMA_ADDRESS)
* that we just need to work around it and always return true.
*/
- if (x == MAX_DMA_ADDRESS)
+ if (x == (unsigned long)MAX_DMA_ADDRESS)
return true;
return false;
but this does not permit differentiating a 0 virtual address from
MAX_DMA_ADDRESS having overflowed.
Thanks!
--
Florian
More information about the linux-arm-kernel
mailing list