From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) by dpdk.org (Postfix) with ESMTP id 3F81B7D97 for ; Wed, 31 May 2017 02:09:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1496189366; x=1527725366; h=from:to:cc:subject:date:message-id:mime-version; bh=PvSoSmXY6hSEZvuXOdJX/LmHX7mrgd7CPkEFZKeUCv8=; b=fB1Tq+5qlQYg3uOaytCaNlLdws96eL9uPzlFzyw7HBxvtyiqbRUe9snc rEqZTFpq6Eb6Mrj3lbMHbZ3XuI6ByHmglEk+GTa0CqaR9Au8ih8NHL9ed 1P1DfHqRy4cfPX5/tylxGmOFcMGUAkiig8e3vI4Rze/BR2qemz4ol2U8T 8=; X-IronPort-AV: E=Sophos;i="5.38,420,1491264000"; d="scan'208";a="549427520" Received: from sea19-co-svc-lb5-vlan2.sea.amazon.com (HELO email-inbound-relay-60004.pdx1.amazon.com) ([10.47.22.162]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 May 2017 00:09:24 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-60004.pdx1.amazon.com (8.14.7/8.14.7) with ESMTP id v4V09INM010122 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 31 May 2017 00:09:23 GMT Received: from EX13d09UWC001.ant.amazon.com (10.43.162.60) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 31 May 2017 00:09:23 +0000 Received: from EX13MTAUWC001.ant.amazon.com (10.43.162.135) by EX13d09UWC001.ant.amazon.com (10.43.162.60) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 31 May 2017 00:09:22 +0000 Received: from dev-dsk-lavignen-2a-i-6727e5bf.us-west-2.amazon.com (172.22.103.204) by mail-relay.amazon.com (10.43.162.232) with Microsoft SMTP Server id 15.0.1104.5 via Frontend Transport; Wed, 31 May 2017 00:09:23 +0000 Received: by dev-dsk-lavignen-2a-i-6727e5bf.us-west-2.amazon.com (Postfix, from userid 3314725) id 03ECF80383; Wed, 31 May 2017 00:09:22 +0000 (UTC) From: Jamie Lavigne To: CC: Jamie Lavigne Date: Wed, 31 May 2017 00:09:00 +0000 Message-ID: <1496189340-27813-1-git-send-email-lavignen@amazon.com> X-Mailer: git-send-email 2.7.3.AMZN MIME-Version: 1.0 Content-Type: text/plain Precedence: Bulk Subject: [dpdk-dev] [PATCH] Correctly handle malloc_elem resize with padding X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 00:09:26 -0000 Currently when a malloc_elem is split after resizing, any padding present in the elem is ignored. This causes the resized elem to be too small when padding is present, and user data can overwrite the beginning of the following malloc_elem. Solve this by including the size of the padding when computing where to split the malloc_elem. Signed-off-by: Jamie Lavigne --- lib/librte_eal/common/malloc_elem.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/lib/librte_eal/common/malloc_elem.c b/lib/librte_eal/common/malloc_elem.c index 42568e1..2ed1942 100644 --- a/lib/librte_eal/common/malloc_elem.c +++ b/lib/librte_eal/common/malloc_elem.c @@ -333,9 +333,11 @@ malloc_elem_resize(struct malloc_elem *elem, size_t size) elem_free_list_remove(next); join_elem(elem, next); - if (elem->size - new_size >= MIN_DATA_SIZE + MALLOC_ELEM_OVERHEAD){ + const size_t new_total_size = new_size + elem->pad; + + if (elem->size - new_total_size >= MIN_DATA_SIZE + MALLOC_ELEM_OVERHEAD){ /* now we have a big block together. Lets cut it down a bit, by splitting */ - struct malloc_elem *split_pt = RTE_PTR_ADD(elem, new_size); + struct malloc_elem *split_pt = RTE_PTR_ADD(elem, new_total_size); split_pt = RTE_PTR_ALIGN_CEIL(split_pt, RTE_CACHE_LINE_SIZE); split_elem(elem, split_pt); malloc_elem_free_list_insert(split_pt); -- 2.7.3.AMZN