[U-Boot] [PATCH v5 2/2] dlmalloc: fix malloc range at end of ram

[Tom Rini]

On Sun, May 05, 2019 at 07:55:10PM +0200, Simon Goldschmidt wrote:
> Am 05.05.2019 um 13:38 schrieb Tom Rini:
> >On Sat, May 04, 2019 at 08:16:38PM +0200, Simon Goldschmidt wrote:
> >>Tom,
> >>
> >>Am 26.04.2019 um 13:00 schrieb Marek Vasut:
> >>>On 4/26/19 12:19 PM, Simon Goldschmidt wrote:
> >>>>On Fri, Apr 26, 2019 at 11:56 AM Marek Vasut <marek.vasut at gmail.com> wrote:
> >>>>>
> >>>>>On 4/26/19 11:36 AM, Simon Goldschmidt wrote:
> >>>>>>On Fri, Apr 26, 2019 at 11:32 AM Marek Vasut <marek.vasut at gmail.com> wrote:
> >>>>>>>
> >>>>>>>On 4/26/19 8:19 AM, Simon Goldschmidt wrote:
> >>>>>>>>Marek Vasut <marek.vasut at gmail.com> schrieb am Fr., 26. Apr. 2019, 00:22:
> >>>>>>>>
> >>>>>>>>>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 at gmail.com>
> >>
> >>Since there's no way this fits without breaking smartweb, I'd rather drop
> >>this for now in order to get 1/2 accepted.
> >
> >I thought that with 1/2 this fit again, with gcc-7.3 at least?  Thanks!
> 
> I'm not sure, as I don't have it here to test. But as this patch doesn't
> actually fix a board but fixes an issue in the code that *might* appear in
> the future, I'm not convinced it would be the right thing to merge it like
> it is.
> 
> And I'm also a little short on time to investigate this further, as it's not
> a real bug, currently.

OK, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190505/862d365b/attachment.sig>