On 4/26/19 8:19 AM, Simon Goldschmidt wrote: > Marek Vasut <marek.va...@gmail.com> schrieb am Fr., 26. Apr. 2019, 00:22: > >> On 4/25/19 9:22 PM, Simon Goldschmidt wrote: >>> If the malloc range passed to mem_malloc_init() is at the end of address >>> range and 'start + size' overflows to 0, following allocations fail as >>> mem_malloc_end is zero (which looks like uninitialized). >>> >>> Fix this by subtracting 1 of 'start + size' overflows to zero. >>> >>> Signed-off-by: Simon Goldschmidt <simon.k.r.goldschm...@gmail.com> >>> --- >>> >>> Changes in v5: >>> - this patch was 1/2 in v4 but is now 2/2 as the 2nd patch of v4 has >>> already been accepted >>> - rearrange the code to make it only 8 bytes plus in code size for arm >>> (which fixes smartweb SPL overflowing) >>> >>> common/dlmalloc.c | 6 +++++- >>> 1 file changed, 5 insertions(+), 1 deletion(-) >>> >>> diff --git a/common/dlmalloc.c b/common/dlmalloc.c >>> index 6f12a18d54..38859ecbd4 100644 >>> --- a/common/dlmalloc.c >>> +++ b/common/dlmalloc.c >>> @@ -601,8 +601,12 @@ void *sbrk(ptrdiff_t increment) >>> void mem_malloc_init(ulong start, ulong size) >>> { >>> mem_malloc_start = start; >>> - mem_malloc_end = start + size; >>> mem_malloc_brk = start; >>> + mem_malloc_end = start + size; >>> + if (size > mem_malloc_end) { >>> + /* overflow: malloc area is at end of address range */ >>> + mem_malloc_end--; >> >> Does this mean a memory wrap-around happened ? >> I don't think decrementing malloc area size by 1 is a proper solution. >> You can have it overflow by 2 and decrementing by 1 won't help. >> > > No, not a real overflow. Instead, as I tried to described in the commit > message, mem_malloc_end gets 0 if the range is at the end of addr range, > e.g. malloc start is 0xffff0000 and malloc size is 0x10000. Subtracting 1 > will be enough here. It reduces the available mall of aize, but I don't > think that should be a problem.
That's a wrap-around . What happens with your example if malloc_size is 0x10001 ? Hint: It fails ... > I got this when experimenting with full heap in socfpga. Due to other > patches not being accepted, this is not an issue currebtly, but can easily > become one on the future. > > Regrds, > Simon > > >>> + } >>> >>> debug("using memory %#lx-%#lx for malloc()\n", mem_malloc_start, >>> mem_malloc_end); >>> >> >> >> -- >> Best regards, >> Marek Vasut >> > -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot