From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Thu, 25 Apr 2019 06:50:50 -0400 Subject: [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram In-Reply-To: References: <20190401200150.1630-1-simon.k.r.goldschmidt@gmail.com> <20190401200150.1630-2-simon.k.r.goldschmidt@gmail.com> <20190424112656.GA31207@bill-the-cat> <20190424115257.GF31207@bill-the-cat> Message-ID: <20190425105050.GJ31207@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Thu, Apr 25, 2019 at 09:32:22AM +0200, Simon Goldschmidt wrote: > On Thu, Apr 25, 2019 at 1:59 AM Simon Glass wrote: > > > > Hi, > > > > On Wed, 24 Apr 2019 at 05:53, Tom Rini wrote: > > > > > > On Wed, Apr 24, 2019 at 01:49:52PM +0200, Simon Goldschmidt wrote: > > > > On Wed, Apr 24, 2019 at 1:27 PM Tom Rini wrote: > > > > > > > > > > On Tue, Apr 23, 2019 at 09:54:10PM -0600, Simon Glass wrote: > > > > > > On Mon, 1 Apr 2019 at 14:01, 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 > > > > > > > --- > > > > > > > > > > > > > > Changes in v4: None > > > > > > > Changes in v3: None > > > > > > > > > > > > > > common/dlmalloc.c | 4 ++++ > > > > > > > 1 file changed, 4 insertions(+) > > > > > > > > > > > > Reviewed-by: Simon Glass > > > > > > > > > > So, the problem with this patch is that it increases the generic malloc > > > > > code size ever so slightly and blows up smartweb :( > > > > > > > > Ehrm, ok, so how do we proceed? > > > > > > A good question. Take a look at spl/u-boot-spl.map on smartweb and see > > > if, of the malloc functions it doesn't discard there's something that > > > maybe could be optimized somewhere? > > > > I wonder if we should have a Kconfig option like SPL_CHECKS which > > enables these sorts of minor checks, which may only fix one board at > > the cost of code size? > > > > Then it could be enabled by default, but disabled on this board? > > For a bigger change, this might be an idea, but for a change that I can cut > down to 16 or even 8 bytes code size increasement, I don't think having a > new option would be good. > > Anyway, I just tried at work and I don't get the overflow. Tom, which gcc > are you using to get the size error? It works for me on Debian 9 but doesn't > work with Ubuntu (both times, default cross compiler toolchain installed). I'm using the gcc-7.3 from kernel.org that we use in travis/etc. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: