From: Marek Vasut <marek.vasut@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v5 2/2] dlmalloc: fix malloc range at end of ram
Date: Fri, 26 Apr 2019 00:22:30 +0200 [thread overview]
Message-ID: <f0c43a10-8874-620d-eb0e-785fdd6ca8d9@gmail.com> (raw)
In-Reply-To: <20190425192240.5925-2-simon.k.r.goldschmidt@gmail.com>
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@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
next prev parent reply other threads:[~2019-04-25 22:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-25 19:22 [U-Boot] [PATCH v5 1/2] spl: fix linker size check off-by-one errors Simon Goldschmidt
2019-04-25 19:22 ` [U-Boot] [PATCH v5 2/2] dlmalloc: fix malloc range at end of ram Simon Goldschmidt
2019-04-25 22:22 ` Marek Vasut [this message]
2019-04-26 6:19 ` Simon Goldschmidt
2019-04-26 9:32 ` Marek Vasut
2019-04-26 9:36 ` Simon Goldschmidt
2019-04-26 9:56 ` Marek Vasut
2019-04-26 10:19 ` Simon Goldschmidt
2019-04-26 11:00 ` Marek Vasut
2019-05-04 18:16 ` Simon Goldschmidt
2019-05-05 11:38 ` Tom Rini
2019-05-05 17:55 ` Simon Goldschmidt
2019-05-05 18:12 ` Tom Rini
2019-04-27 20:17 ` [U-Boot] [PATCH v5 1/2] spl: fix linker size check off-by-one errors Simon Goldschmidt
2019-05-06 11:14 ` Tom Rini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f0c43a10-8874-620d-eb0e-785fdd6ca8d9@gmail.com \
--to=marek.vasut@gmail.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox