Tom, Am Donnerstag, 11. Juli 2024, 17:45:17 CEST schrieb Tom Rini: > The problem here is that "zalloc" is inline and so this change causes > about 1KiB of growth on platforms which enable ext4 and so at least > mx6sabresd now overflows it's maximum size. Looking harder, I think the > best solution here would be for ext4 to stop using its own wrapper and > instead call our kzalloc compatibility function.
As discussed on IRC yesterday, moving to kzalloc() is fine. But the crash around malloc() still needs a fix. Last night I investigated further why u-boot's malloc() implementation crashes on my x86_64 test bed when ext4 tries to allocate a lot of memory. It turned out that it's an integer overflow around malloc_extend_top() and sbrk(). malloc_extend_top() uses a size_t to calculate the amount of required memory and sbrk() takes an ptrdiff_t type. On x86_64, u-boot seems to use unsigned long for size_t but just an int for ptrdiff_t. This is causing the trouble. How about this? diff --git a/arch/x86/include/asm/posix_types.h b/arch/x86/include/asm/posix_types.h index dbcea7f47f..e1ed9bcabc 100644 --- a/arch/x86/include/asm/posix_types.h +++ b/arch/x86/include/asm/posix_types.h @@ -20,11 +20,12 @@ typedef unsigned short __kernel_gid_t; #if defined(__x86_64__) typedef unsigned long __kernel_size_t; typedef long __kernel_ssize_t; +typedef long __kernel_ptrdiff_t; #else typedef unsigned int __kernel_size_t; typedef int __kernel_ssize_t; -#endif typedef int __kernel_ptrdiff_t; +#endif typedef long __kernel_time_t; typedef long __kernel_suseconds_t; typedef long __kernel_clock_t; Thanks, //richard -- sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr: ATU 66964118 | FN: 374287y
