malloc: Use malloc simple before malloc is fully initialized in memalign()

Follow implementation in mALLOc(). Check GD_FLG_FULL_MALLOC_INIT flag and use
malloc_simple if GD_FLG_FULL_MALLOC_INIT is u

malloc: Use malloc simple before malloc is fully initialized in memalign()

Follow implementation in mALLOc(). Check GD_FLG_FULL_MALLOC_INIT flag and use
malloc_simple if GD_FLG_FULL_MALLOC_INIT is unset. Adjust the malloc bytes
to align with the requested alignment.

The original memalign() function will access mchunkptr struct to adjust the
alignment if there is misalignment happen, but mchunkptr struct is not being
initialized before full malloc is initialized. This cause the system crash.

Signed-off-by: Ley Foon Tan <ley.foon.tan@intel.com>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>

show more ...

malloc: don't compare pointers to 0

0 is not a pointer. So do not compare pointers to 0.

Do not return 0 from functions with a pointer return
type.

Problem identified with Coccinelle.

Signed-off-

malloc: don't compare pointers to 0

0 is not a pointer. So do not compare pointers to 0.

Do not return 0 from functions with a pointer return
type.

Problem identified with Coccinelle.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

show more ...

spl: make SPL and normal u-boot stage use independent SYS_MALLOC_F_LEN

Some platforms have very limited SRAM to run SPL code, so there may
not be the same amount space for a malloc pool before reloc

spl: make SPL and normal u-boot stage use independent SYS_MALLOC_F_LEN

Some platforms have very limited SRAM to run SPL code, so there may
not be the same amount space for a malloc pool before relocation in
the SPL stage as the normal U-Boot stage.

Make SPL and (the full) U-Boot stage use independent SYS_MALLOC_F_LEN,
so the size of pre-relocation malloc pool can be configured memory
space independently.

Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
[fixed up commit-message:]
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

show more ...

malloc: Turn on DEBUG when enabling unit tests

Unit tests require mallinfo which in turn requires DEBUG on
dlmalloc to be enabled.

The dependancy on CONFIG_SANDBOX is wrong.

Signed-off-by: Panteli

malloc: Turn on DEBUG when enabling unit tests

Unit tests require mallinfo which in turn requires DEBUG on
dlmalloc to be enabled.

The dependancy on CONFIG_SANDBOX is wrong.

Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot

malloc: improve memalign fragmentation fix

Commit 4f144a416469 "malloc: work around some memalign fragmentation
issues" enhanced memalign() so that it can succeed in more cases where
heap fragmentat

malloc: improve memalign fragmentation fix

Commit 4f144a416469 "malloc: work around some memalign fragmentation
issues" enhanced memalign() so that it can succeed in more cases where
heap fragmentation is present. However, it did not solve as many cases
as it could. This patch enhances the code to cover more cases.

The alignment code works by allocating more space than the user requests,
then adjusting the returned pointer to achieve alignment. In general, one
must allocate "alignment" bytes more than the user requested in order to
guarantee that alignment is possible. This is what the original code does.
The previous enhancement attempted a second allocation if the padded
allocation failed, and succeeded if that allocation just happened to be
aligned; a fluke that happened often in practice. There are still cases
where this could fail, yet where it is still possible to honor the user's
allocation request. In particular, if the heap contains a free region that
is large enough for the user's request, and for leading padding to ensure
alignment, but has no or little space for any trailing padding. In this
case, we can make a third(!) allocation attempt after calculating exactly
the size of the leading padding required to achieve alignment, which is
the minimal over-allocation needed for the overall memalign() operation to
succeed if the third and second allocations end up at the same location.

This patch isn't checkpatch-clean, since it conforms to the existing
coding style in dlmalloc.c, which is different to the rest of U-Boot.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

show more ...

common/dlmalloc.c: Delete content that was moved to malloc.h

Remove several hundred lines of content surrounded by:

#if 0 /* Moved to malloc.h */
... moved stuff ...
#endif /* 0 */

common/dlmalloc.c: Delete content that was moved to malloc.h

Remove several hundred lines of content surrounded by:

#if 0 /* Moved to malloc.h */
... moved stuff ...
#endif /* 0 */ /* Moved to malloc.h */

Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Reviewed-by: Tom Rini <trini@konsulko.com>

show more ...

malloc: remove !gd handling

Following the previous patch, malloc() is never called before gd is set,
so we can remove the special-case check for this condition.

This reverts commit 854d2b9753e4 "dl

malloc: remove !gd handling

Following the previous patch, malloc() is never called before gd is set,
so we can remove the special-case check for this condition.

This reverts commit 854d2b9753e4 "dlmalloc: ensure gd is set for early
alloc".

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>

show more ...

malloc: solve dead code issue in memalign()

The recent change to memalign() caused the allocation failure detection
code to be dead code; the "retry" logic is always activated under the same
conditi

malloc: solve dead code issue in memalign()

The recent change to memalign() caused the allocation failure detection
code to be dead code; the "retry" logic is always activated under the same
condition that the original failure detection code is, and also fully
handles any possible failures. This patch solves the presence of dead
code.

Two alternatives are possible:

a) Delete the now-dead test, and rely on the "retry" path to handle any
allocation problems, as it does.

b) Make the "retry" path fall through to the existing (currently dead)
failure detection code, thus making it not-dead.

(b) was chosen since it reduces the diff between U-Boot's and the upstream
dlmalloc. This should make it marginally easier to import a new version of
dlmalloc in the future.

Reported by: Coverity Scan
Fixes: 4f144a416469 ("malloc: work around some memalign fragmentation issues")
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

show more ...

malloc: work around some memalign fragmentation issues

Use of memalign can trigger fragmentation issues such as:

// Internally, this needs to find a free block quite bit larger than s.
// Once the

malloc: work around some memalign fragmentation issues

Use of memalign can trigger fragmentation issues such as:

// Internally, this needs to find a free block quite bit larger than s.
// Once the free region is found, any unaligned "padding" immediately
// before and after the block is marked free, so that the allocation
// takes only s bytes (plus malloc header overhead).
p = memalign(a, s);
// If there's little fragmentation so far, this allocation is likely
// located immediately after p.
p2 = malloc(x);
free(p);
// In theory, this should return the same value for p. However, the hole
// left by the free() call is only s in size (plus malloc header overhead)
// whereas memalign searches for a larger block in order to guarantee it
// can adjust the returned pointer to the alignment requirements. Hence,
// the pointer returned, if any, won't be p. If there's little or no space
// left after p2, this allocation will fail.
p = memalign(a, s);

In practice, this issue occurs when running the "dfu" command repeatedly
on NVIDIA Tegra boards, since DFU allocates a large 32M data buffer, and
then initializes the USB controller. If this is the first time USB has
been used in the U-Boot session, this causes a probe of the USB driver,
which causes various allocations, including a strdup() of a GPIO name
when requesting the VBUS GPIO. When DFU is torn down, the USB driver
is left probed, and hence its memory is left allocated. If "dfu" is
executed again, allocation of the 32M data buffer fails as described
above.

In practice, there is a memory hole exactly large enough to hold the 32M
data buffer than DFU needs. However, memalign() can't know that in a
general way. Given that, it's particularly annoying that the allocation
fails!

The issue is that memalign() tries to allocate something larger to
guarantee the ability to align the returned pointer. This patch modifies
memalign() so that if the "general case" over-sized allocation fails,
another allocation is attempted, of the exact size the user desired. If
that allocation just happens to be aligned in the way the user wants,
(and in the case described above, it will be, since the free memory
region is located where a previous identical allocation was located),
the pointer can be returned.

This patch is somewhat related to 806bd245b1ab "dfu: don't keep
freeing/reallocating". That patch worked around the issue by removing
repeated free/memalign within a single execution of "dfu". However,
the same technique can't be applied across multiple invocations, since
there's no reason to keep the DFU buffer allocated while DFU isn't
running. This patch addresses the root-cause a bit more directly.

This problem highlights some of the disadvantages of dynamic allocation
and deferred probing of devices.

This patch isn't checkpatch-clean, since it conforms to the existing
coding style in dlmalloc.c, which is different to the rest of U-Boot.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>

show more ...

Merge branch 'u-boot/master' into 'u-boot-arm/master'

Merge branch 'master' of git://git.denx.de/u-boot-dm

Move initf_malloc() to a common place

To allow this function to be used from SPL, move it to the malloc()
code.

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

dlmalloc: do memset in malloc init as new default config

This commit introduces new config: CONFIG_SYS_MALLOC_CLEAR_ON_INIT.

This config is an expert option and is enabled by default.

The all amou

dlmalloc: do memset in malloc init as new default config

This commit introduces new config: CONFIG_SYS_MALLOC_CLEAR_ON_INIT.

This config is an expert option and is enabled by default.

The all amount of memory reserved for the malloc, is by default set
to zero in mem_malloc_init(). When the malloc reserved memory exceeds
few MiB, then the boot process can slow down.

So disabling this config, is an expert option to reduce the boot time,
and can be disabled by Kconfig.

Note:
After disable this option, only calloc() will return the pointer
to the zeroed memory area. Previously, without this option,
the memory pointed to untouched malloc memory region, was filled
with zeros. So it means, that code with malloc() calls should
be reexamined.

Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

Merge git://git.denx.de/u-boot-dm

Conflicts:
drivers/serial/serial-uclass.c

Signed-off-by: Tom Rini <trini@ti.com>

dm: Split the simple malloc() implementation into its own file

The simple malloc() implementation is used when memory is tight. It provides
a simple buffer with an incrementing pointer.

At present

dm: Split the simple malloc() implementation into its own file

The simple malloc() implementation is used when memory is tight. It provides
a simple buffer with an incrementing pointer.

At present the implementation is inside dlmalloc. Move it into its own file
so that it is easier to find.

Rather than using relocation as a signal that the full malloc() is
available, add a special GD_FLG_FULL_MALLOC_INIT flag. This signals that the
simple malloc() should no longer be used.

In some cases, such as SPL, even the code space used by the full malloc() is
wasteful. Add a CONFIG_SYS_MALLOC_SIMPLE option to provide only the simple
malloc. In this case the full malloc is not available at all. It saves about
1KB of code space and about 0.5KB of data on Thumb 2.

Acked-by: Tom Rini <trini@ti.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot-arm

malloc: Output region when debugging

When DEBUG is set, output memory region used for malloc().

Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>

dlmalloc: ensure gd is set for early alloc

Attempting to run the sandbox leads to a segfault, because some dynamic
libraries (outside of u-boot) attempt to use malloc() to allocate memory
before u-b

dlmalloc: ensure gd is set for early alloc

Attempting to run the sandbox leads to a segfault, because some dynamic
libraries (outside of u-boot) attempt to use malloc() to allocate memory
before u-boot's gd variable is initialized.

Check for gd not being NULL in the SYS_MALLOC_F_LEN handling, so that
malloc() doesn't crash when called at this point.

$ gdb -q --args ./u-boot
(gdb) r
Program received signal SIGSEGV, Segmentation fault.
0x0000000000412b9b in malloc (bytes=bytes@entry=37) at common/dlmalloc.c:2184
2184 if (!(gd->flags & GD_FLG_RELOC)) {
(gdb) p gd
$1 = (gd_t *) 0x0
(gdb) bt
#0 0x0000000000412b9b in malloc (bytes=bytes@entry=37) at common/dlmalloc.c:2184
#1 0x00007ffff75bf8e1 in set_binding_values (domainname=0x7ffff11f4f12 "libgpg-error", dirnamep=0x7fffffffe168, codesetp=0x0)
at bindtextdom.c:228
#2 0x00007ffff75bfb4c in set_binding_values (codesetp=0x0, dirnamep=0x7fffffffe168, domainname=<optimized out>) at bindtextdom.c:350
#3 __bindtextdomain (domainname=<optimized out>, dirname=0x7ffff11f4f00 "/usr/share/locale") at bindtextdom.c:348
#4 0x00007ffff11eca17 in ?? () from /lib/x86_64-linux-gnu/libgpg-error.so.0
#5 0x00007ffff7dea9fa in call_init (l=<optimized out>, argc=argc@entry=1, argv=argv@entry=0x7fffffffe208,
env=env@entry=0x7fffffffe218) at dl-init.c:78
#6 0x00007ffff7deaae3 in call_init (env=0x7fffffffe218, argv=0x7fffffffe208, argc=1, l=<optimized out>) at dl-init.c:36
#7 _dl_init (main_map=0x7ffff7ffe1a8, argc=1, argv=0x7fffffffe208, env=0x7fffffffe218) at dl-init.c:126
#8 0x00007ffff7ddd1ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2

Signed-off-by: Rabin Vincent <rabin@rab.in>
Acked-by: Simon Glass <sjg@chromium.org>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot-arm

sandbox: Always enable malloc debug

Tun on DEBUG in malloc(). This adds code space and slows things down but
for sandbox this is acceptable. We gain the ability to check for memory
leaks in tests.

sandbox: Always enable malloc debug

Tun on DEBUG in malloc(). This adds code space and slows things down but
for sandbox this is acceptable. We gain the ability to check for memory
leaks in tests.

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

show more ...

Add a simple malloc() implementation for pre-relocation

If we are to have driver model before relocation we need to support some
way of calling memory allocation routines.

The standard malloc() is

Add a simple malloc() implementation for pre-relocation

If we are to have driver model before relocation we need to support some
way of calling memory allocation routines.

The standard malloc() is pretty complicated:

1. It uses some BSS memory for its state, and BSS is not available before
relocation

2. It supports algorithms for reducing memory fragmentation and improving
performace of free(). Before relocation we could happily just not support
free().

3. It includes about 4KB of code (Thumb 2) and 1KB of data. However since
this has been loaded anyway this is not really a problem.

The simplest way to support pre-relocation malloc() is to reserve an area
of memory and allocate it in increasing blocks as needed. This
implementation does this.

To enable it, you need to define the size of the malloc() pool as described
in the README. It will be located above the pre-relocation stack on
supported architectures.

Note that this implementation is only useful on machines which have some
memory available before dram_init() is called - this includes those that
do no DRAM init (like tegra) and those that do it in SPL (quite a few
boards). Enabling driver model preior to relocation for the rest of the
boards is left for a later exercise.

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

show more ...

Remove form-feeds from dlmalloc.c

These don't really serve any purpose in the modern age. On the other hand
they show up as annoying control characters in my editor, which then happily
removes them.

Remove form-feeds from dlmalloc.c

These don't really serve any purpose in the modern age. On the other hand
they show up as annoying control characters in my editor, which then happily
removes them.

I believe we can drop these characters from the file.

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

show more ...

Merge branch 'u-boot/master' into 'u-boot-arm/master'

Conflicts:
drivers/video/exynos_fb.c

Consolidate bool type

'bool' is defined in random places. This patch consolidates them into a
single header file include/linux/types.h, using stdbool.h introduced in C99.

All other #define, typedef

Consolidate bool type

'bool' is defined in random places. This patch consolidates them into a
single header file include/linux/types.h, using stdbool.h introduced in C99.

All other #define, typedef and enum are removed. They are all consistent with
true = 1, false = 0.

Replace FALSE, False with false. Replace TRUE, True with true.
Skip *.py, *.php, lib/* files.

Signed-off-by: York Sun <yorksun@freescale.com>

show more ...