[U-Boot] [PATCH v5 2/2] dlmalloc: fix malloc range at end of ram

[Marek Vasut]

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.goldschmidt at 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.

> +	}
>  
>  	debug("using memory %#lx-%#lx for malloc()\n", mem_malloc_start,
>  	      mem_malloc_end);
> 


-- 
Best regards,
Marek Vasut