From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Fri, 1 May 2020 17:56:26 -0400 Subject: [PATCH v2 3/3] arm: caches: manage phys_addr_t overflow in mmu_set_region_dcache_behaviour In-Reply-To: <20200424201957.v2.3.Ic2c7c6923035711a4c653d52ae7c0f57ca6f9210@changeid> References: <20200424182017.11852-1-patrick.delaunay@st.com> <20200424201957.v2.3.Ic2c7c6923035711a4c653d52ae7c0f57ca6f9210@changeid> Message-ID: <20200501215626.GN12564@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 Fri, Apr 24, 2020 at 08:20:17PM +0200, Patrick Delaunay wrote: > Solved the overflow on phys_addr_t type for start + size in > mmu_set_region_dcache_behaviour() function. > > This overflow is avoided by dividing start and end by 2 before addition, > and we only expecting that start and size are even. > > This patch doesn't change the current function behavior if the > parameters (start or size) are not aligned on MMU_SECTION_SIZE. > > For example, this overflow occurs on ARM32 with: > start = 0xC0000000 and size = 0x40000000 > then start + size = 0x100000000 and end = 0x0. > > For information the function behavior change with risk of regression, > if we just shift start and size before the addition. > Example with 2MB section size: > MMU_SECTION_SIZE 0x200000 and MMU_SECTION_SHIFT = 21 > with start = 0x1000000, size = 0x1000000, > - with the proposed patch, start = 0 and end = 0x1 as previously > - with the more simple patch: > end = (start >> MMU_SECTION_SHIFT) + (size >> MMU_SECTION_SHIFT) > the value of end change: > start >> 21 = 0, size >> 21 = 0 and end = 0x0 !!! > > Signed-off-by: Patrick Delaunay Applied to u-boot/master, thanks! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: