Hello Simon,
On 02/02/2015 07:15 PM, Simon Glass wrote:
Hi Lukasz,
On 2 February 2015 at 01:46, Lukasz Majewski <l.majew...@samsung.com> wrote:
Dear All,
And the next is interesting.
odroid_defconfig has more than 80MB for malloc (we need about 64mb
for the DFU now, to be able write 32MB file).
This is the CONFIG_SYS_MALLOC_LEN. And the memory area for malloc is
set to 0 in function mem_malloc_init(). So for this config that
function sets more than 80MB to zero.
This is not good, because we shouldn't expect zeroed memory returned
by malloc pointer. This is a job for calloc.
Especially if some command expects zeroed memory after malloc,
probably after few next calls - it can crash...
I think that the above excerpt is _really_ important and should be
discussed.
I've "cut" it from the original post, so it won't get lost between the
lines.
It seems really strange, that malloc() area is cleared after
relocation. Which means that all "first" malloc'ed buffers get
implicitly zeroed.
Przemek is right here that this zeroing shouldn't be performed.
I'm also concerned about potential bugs, which show up (or even worse -
won't show up soon) after this change.
Hence, I would like to ask directly the community about the possible
solutions.
Please look at: ./common/dlmalloc.c mem_alloc_init() function [1].
On the one hand removing memset() at [1] speeds up booting time and
makes malloc() doing what is is supposed to do.
On the other hand there might be in space some boards, which rely on
this memset and without it some wired things may start to happening.
I think removing it is a good idea. It was one optimisation that I did
for boot time in the Chromium tree. If you do it now (and Tom agrees)
then there is plenty of time to test for this release cycle. You could
go further and add a test CONFIG which fills it with some other
non-zero value.
Regards,
Simon
Filling the malloc area with some pattern was a good idea to find out,
why my trats2 had some issue after skip the memset with zeros in malloc
init.
And actually the issue was not in malloc call, but it was in calloc.
The present implementation assumes that memory reserved for malloc
is zeroed at init. And the calloc do the check, how much of the
allocated memory is fresh(doesn't require zeroing).
After skip this fresh memory check, the calloc works fine.
Anyway, I think that this should be optional and tested on every config,
before enable.
I would like to test something and will send the updated patch set on
Monday.
Best regards,
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
