From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f66.google.com (mail-wm0-f66.google.com [74.125.82.66]) by dpdk.org (Postfix) with ESMTP id 6DE3B1B294 for ; Fri, 26 Jan 2018 14:14:15 +0100 (CET) Received: by mail-wm0-f66.google.com with SMTP id j21so26653550wmh.1 for ; Fri, 26 Jan 2018 05:14:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=mRN5IdAJzluGqUG4YUjstk4+fk2E1QVBbVwWvp9yyNs=; b=hk2S95YlmPU07C//j/N5eKr/rv3iw6AGruvHqsOecq+dTwke8jbfuT+XpyAM233wd4 qZGrSbx/9t8eb/wB1y7o4xcrlkY9Bg823HIB7UH00HexcBloNcMbEwK0VB9XZOWSkBMi jZHuFDfylsZhwN3grCGeXFhFTq7PPDfR4WFZAF7nMlZwxNl2OYLHZn9ex3eAUpm46pHh +NlkbGh0aNSD1FBQVQbst5+Uj3BUoErqaDJ7ZfQBa0eExyrPeRjMYX2shj4kj/oTRCEM 5cIYjIQo88imPJmxt/sCyXn+KH8N29WjMx85XYkgGTRPEiRcyRb122Qs082H7Wjbdzpj syxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=mRN5IdAJzluGqUG4YUjstk4+fk2E1QVBbVwWvp9yyNs=; b=Elsa8RTPbQ0vS5uJai9Ws3rX7cpYpGjtpQffWSnapd61La2UgxKnUG9MZYeQTqAYH6 uzT/AjNx+oPG8vxHADWbHz5O1VIK1BuB1/8nxyx27kH7yW+zU8xGi1MK3/9zrXki+5jx UGKOAzEeZTeaURYSeabk8xrKriSrDSqKFd9Y5cliVtcLFzpTOUY/OV5uqqU4CgJTqPu2 OqWBzskis8jMStba81cmYmJ2TmIGG9neEjhcT6F/uYWowEto2/fsvpUNSKnDMMKEsNmU tVek0NTqhToYWk1iGBCnkDsKL0O9m8BRb/nhqa6PyLiAjou/kCY04hQR7Jw4sZPfWA4w GSZA== X-Gm-Message-State: AKwxyte2PIpmxzLBiG8Rwv3plAY7dqgPcDCfwrlVjm5K0Fb9k/9kO37s YNyFHpRnR6WSAkVgCdpezVg= X-Google-Smtp-Source: AH8x2259jfq9R1W6igQM/5Xy5mxD7jkakE9VT+qwtdh5+jV6dzDmg5GrlSixFJnoIhDu0Csb5Aonrg== X-Received: by 10.28.13.138 with SMTP id 132mr9754370wmn.5.1516972455159; Fri, 26 Jan 2018 05:14:15 -0800 (PST) Received: from localhost ([2a00:23c5:bef3:400:9531:588b:44ae:bec4]) by smtp.gmail.com with ESMTPSA id n24sm4463371wmi.21.2018.01.26.05.14.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 26 Jan 2018 05:14:14 -0800 (PST) From: luca.boccassi@gmail.com To: Anatoly Burakov Cc: dpdk stable Date: Fri, 26 Jan 2018 13:12:40 +0000 Message-Id: <20180126131332.15346-10-luca.boccassi@gmail.com> X-Mailer: git-send-email 2.14.2 In-Reply-To: <20180126131332.15346-1-luca.boccassi@gmail.com> References: <20180126131332.15346-1-luca.boccassi@gmail.com> Subject: [dpdk-stable] patch 'malloc: fix end for bounded elements' has been queued to LTS release 16.11.5 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 13:14:15 -0000 Hi, FYI, your patch has been queued to LTS release 16.11.5 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 01/28/18. So please shout if anyone has objections. Thanks. Luca Boccassi --- >>From 8d84c383b7262434ff8e93e03be60fdb2a3e07db Mon Sep 17 00:00:00 2001 From: Anatoly Burakov Date: Thu, 21 Dec 2017 16:54:24 +0000 Subject: [PATCH] malloc: fix end for bounded elements [ upstream commit 20d2159d4640a1844a5856d8d8df86cf0b24b7c1 ] 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") Signed-off-by: Anatoly Burakov --- lib/librte_eal/common/malloc_elem.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/librte_eal/common/malloc_elem.c b/lib/librte_eal/common/malloc_elem.c index 77a86151b..e2bd3ac21 100644 --- a/lib/librte_eal/common/malloc_elem.c +++ b/lib/librte_eal/common/malloc_elem.c @@ -98,6 +98,7 @@ elem_start_pt(struct malloc_elem *elem, size_t size, unsigned align, if ((new_data_start & bmask) != ((end_pt - 1) & bmask)) { end_pt = RTE_ALIGN_FLOOR(end_pt, bound); new_data_start = RTE_ALIGN_FLOOR((end_pt - size), align); + end_pt = new_data_start + size; if (((end_pt - 1) & bmask) != (new_data_start & bmask)) return NULL; } -- 2.14.2