From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Fri, 26 Apr 2019 00:22:30 +0200 Subject: [U-Boot] [PATCH v5 2/2] dlmalloc: fix malloc range at end of ram In-Reply-To: <20190425192240.5925-2-simon.k.r.goldschmidt@gmail.com> References: <20190425192240.5925-1-simon.k.r.goldschmidt@gmail.com> <20190425192240.5925-2-simon.k.r.goldschmidt@gmail.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > --- > > 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