It is helpful to test that out-of-memory checks work correctly in code
that calls malloc().

Add a simple way to force failure after a given number of malloc() calls.

Fix a header guard to avoid a build error on sandbox_vpl.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Sean Anderson <seanga2@gmail.com>

This annotates malloc and friends so that valgrind can track the heap. To
do this, we need to follow a few rules:

* Call VALGRIND_MALLOCLIKE_BLOCK whenever we malloc something
* Call VALGRIND_FREELIKE_BLOCK whenever we free something (generally after
  we have done our bookkeeping)
* Call VALGRIND_RESIZEINPLACE_BLOCK whenever we change the size of an
  allocation. We don't record the original request size of a block, and
  neither does valgrind. For this reason, we pretend that the old size of
  the allocation was for 0 bytes. This marks the whole allocaton as
  undefined, so in order to mark all bits correctly, we must make the whole
  new allocation defined with VALGRIND_MAKE_MEM_DEFINED. This may cause us
  to miss some invalid reads, but there is no way to detect these without
  recording the original size of the allocation.

In addition to the above, dlmalloc itself tends to make a lot of accesses
which we know are safe, but which would be unsafe outside of dlmalloc. For
this reason, we provide a suppression file which ignores errors ocurring in
dlmalloc.c

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

The original code is in the public domain. Licenses/README states that the
general license for U-Boot is GPL 2.0+. So we can mark the malloc code as
GPL 2.0+ too.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Export this function always so it can be used behind IS_ENABLED() instead
of requiring an #ifdef.

Signed-off-by: Simon Glass <sjg@chromium.org>

Compiling the sandbox fails on armv7 due to conflicting definitions of
memcpy() and memset() in include/malloc.h and include/linux/string.h.

Use linux/string.h here.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

In order to allow use of both U-Boot's malloc() and the C library's
version, set a prefix for the allocation functions so that they can
co-exist.

This is only done for sandbox. For other archs everything remains the
same.

Signed-off-by: Simon Glass <sjg@chromium.org>

When using memalign() in a scenario where U-Boot is configured for full
malloc support with simple malloc not explicitly enabled and before the
full malloc support is initialized, a memory block is being allocated
and returned without the alignment parameter getting honored.

Fix this issue by replacing the existing memalign pre-full malloc init
logic with a call to memalign_simple() this way ensuring proper alignment
of the returned memory block.

Fixes: ee038c58d519 ("malloc: Use malloc simple before malloc is fully initialized in memalign()")
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

It is sometimes useful to see what memory is being allocated early during
boot. Add logging to support this, using a new LOGC_ALLOC category.

Signed-off-by: Simon Glass <sjg@chromium.org>

When running sandbox, the following phases occur, each with different
malloc implementations or behaviors:

1) Dynamic linker execution, using the dynamic linker's own malloc()
implementation. This is fully functional.

2) After U-Boot's malloc symbol has been hooked into the GOT, but before
any U-Boot code has run. This phase is entirely non-functional, since
U-Boot's gd symbol is NULL and U-Boot's initf_malloc() and
mem_malloc_init() have not been called.

At least on Ubuntu Xenial, the dynamic linker does make both malloc() and
free() calls during this phase. Currently these free() calls crash since
they dereference gd, which is NULL.

U-Boot itself makes no use of malloc() during this phase.

3) U-Boot execution after gd is set and initf_malloc() has been called.
This is fully functional, albeit via a very simple malloc()
implementation.

4) U-Boot execution after mem_malloc_init() has been called. This is fully
functional with a complete malloc() implementation.

Furthermore, if code that called malloc() during phase 1 calls free() in
phase 3 or later, it is likely that heap corruption will occur, since
U-Boot's malloc implementation will assume the pointer is part of its own
heap, although it isn't. I have not actively observed this happening.

To prevent phase 2 from happening, this patch makes all of U-Boot's malloc
library public symbols have hidden visibility. This prevents them from
being hooked into the GOT, so only code in the U-Boot binary itself
actually calls them; any other code will call into the standard C library
malloc(). This also avoids the "furthermore" issue mentioned above.

I have seen references to this GCC pragma in blog posts from 2008, and
RHEL5's ancient gcc appears to accept it fine, so I believe it's quite
safe to use it without checking gcc version.

Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

common/dlmalloc.c is quite big, both in .text and .data usage, therefor
on some boards the SPL is build to use only malloc_simple.c and not the
dlmalloc.c code. This is done in various include/configs/foo.h with the
following construct:

 #ifdef CONFIG_SPL_BUILD
 #define CONFIG_SYS_MALLOC_SIMPLE
 #endif

This commit introduces a SPL_MALLOC_SIMPLE Kconfig bool which allows
selecting this functionality through Kconfig instead.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Simon Glass <sjg@chromium.org>