u-boot.git/common/dlmalloc.c, branch v2016.11-rc2

malloc: improve memalign fragmentation fix

2016-05-23T15:50:17+00:00

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 
Reviewed-by: Tom Rini

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

2016-04-25T19:10:36+00:00

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 
Reviewed-by: Tom Rini

malloc: remove !gd handling

2016-03-08T20:01:47+00:00

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 
Signed-off-by: Stephen Warren 
Reviewed-by: Tom Rini 
Reviewed-by: Simon Glass

malloc: solve dead code issue in memalign()

2016-02-08T15:22:38+00:00

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 
Reviewed-by: Tom Rini

malloc: work around some memalign fragmentation issues

2016-02-01T22:08:43+00:00

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 
Reviewed-by: Tom Rini 
Acked-by: Lukasz Majewski

Move initf_malloc() to a common place

2015-04-23T15:05:53+00:00

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

Signed-off-by: Simon Glass

dlmalloc: do memset in malloc init as new default config

2015-03-09T15:13:28+00:00

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 
Reviewed-by: Simon Glass

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

2014-11-21T07:12:28+00:00

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 
Signed-off-by: Simon Glass

malloc: Output region when debugging

2014-11-12T06:25:42+00:00

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

Signed-off-by: Thierry Reding 
Acked-by: Simon Glass

dlmalloc: ensure gd is set for early alloc

2014-11-07T21:27:05+00:00

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=) at bindtextdom.c:350
 #3  __bindtextdomain (domainname=, 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=, 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=) 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 
Acked-by: Simon Glass