From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Goldschmidt Date: Thu, 25 Apr 2019 21:24:35 +0200 Subject: [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram In-Reply-To: <20190425105050.GJ31207@bill-the-cat> 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> <20190425105050.GJ31207@bill-the-cat> Message-ID: <7d140164-79ab-b1c6-c452-c794a2902eb8@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Am 25.04.2019 um 12:50 schrieb Tom Rini: > 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. Ok, so I have gcc-7.3 on my Ubuntu machine as well. I don't know why 6.3 seems to produce smaller binaries (I thought they were getting smaller with new versions, not larger). However, I've stripped down that patch to +8 Bytes only and sent v5. Regards, Simon