From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH] eal: fix end for bounded malloc elements Date: Fri, 12 Jan 2018 15:54:33 +0100 Message-ID: <17429603.yn0ZjX41h2@xps> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org, stable@dpdk.org To: Anatoly Burakov Return-path: In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 21/12/2017 17:54, Anatoly Burakov: > In cases when alignment is bigger than boundary, we may incorrectly > calculate end of a bounded malloc element. > > Consider this: suppose we are allocating a bounded malloc element > that should be of 128 bytes in size, bounded to 128 bytes and > aligned on a 256-byte boundary. Suppose our malloc element ends > at 0x140 - that is, 256 plus one cacheline. > > So, right at the start, we are aligning our new_data_start to > include the required element size, and to be aligned on a specified > boundary - so new_data_start becomes 0. This fails the following > bounds check, because our element cannot go above 128 bytes from > the start, and we are at 320. So, we enter the bounds handling > branch. > > While we're in there, we are aligning end_pt to our boundedness > requirement of 128 byte, and end up with 0x100 (since 256 is > 128-byte aligned). We recalculate new_data_size and it stays at > 0, however our end is at 0x100, which is beyond the 128 byte > boundary, and we report inability to reserve a bounded element > when we could have. > > This patch adds an end_pt recalculation after new_data_start > adjustment - we already know that size <= bound, so we can do it > safely - and we then correctly report that we can, in fact, try > using this element for bounded malloc allocation. > > Fixes: fafcc11985a2 ("mem: rework memzone to be allocated by malloc") > Cc: sergio.gonzalez.monroy@intel.com > Cc: stable@dpdk.org > Signed-off-by: Anatoly Burakov It looks to be a headache, but as the maintainer of DPDK memory, I trust you :) Applied, thanks