diff mbox

[dpdk-dev,v3] mem: fix malloc_elem resize with padding

Message ID 1496949137-8106-1-git-send-email-lavignen@amazon.com (mailing list archive)
State Accepted, archived
Headers

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK

Commit Message

Jamie Lavigne June 8, 2017, 7:12 p.m. UTC 
  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.

Fixes: af75078fece3 ("first public release")

Signed-off-by: Jamie Lavigne <lavignen@amazon.com>
---
 lib/librte_eal/common/malloc_elem.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

Comments

Sergio Gonzalez Monroy June 20, 2017, 10:18 a.m. UTC | #1 
On 08/06/2017 20:12, Jamie Lavigne wrote:
> 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.
>
> Fixes: af75078fece3 ("first public release")
>
> Signed-off-by: Jamie Lavigne <lavignen@amazon.com>
> ---

Acked-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
Thomas Monjalon June 28, 2017, 9:12 p.m. UTC | #2 
20/06/2017 12:18, Sergio Gonzalez Monroy:
> On 08/06/2017 20:12, Jamie Lavigne wrote:
> > 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.
> >
> > Fixes: af75078fece3 ("first public release")
> >
> > Signed-off-by: Jamie Lavigne <lavignen@amazon.com>
> 
> Acked-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>

Applied, thanks
diff mbox

Patch

diff --git a/lib/librte_eal/common/malloc_elem.c b/lib/librte_eal/common/malloc_elem.c
index 42568e1..08516af 100644
--- a/lib/librte_eal/common/malloc_elem.c
+++ b/lib/librte_eal/common/malloc_elem.c
@@ -314,17 +314,16 @@  malloc_elem_free(struct malloc_elem *elem)
 int
 malloc_elem_resize(struct malloc_elem *elem, size_t size)
 {
-	const size_t new_size = size + MALLOC_ELEM_OVERHEAD;
+	const size_t new_size = size + elem->pad + MALLOC_ELEM_OVERHEAD;
 	/* if we request a smaller size, then always return ok */
-	const size_t current_size = elem->size - elem->pad;
-	if (current_size >= new_size)
+	if (elem->size >= new_size)
 		return 0;
 
 	struct malloc_elem *next = RTE_PTR_ADD(elem, elem->size);
 	rte_spinlock_lock(&elem->heap->lock);
 	if (next ->state != ELEM_FREE)
 		goto err_return;
-	if (current_size + next->size < new_size)
+	if (elem->size + next->size < new_size)
 		goto err_return;
 
 	/* we now know the element fits, so remove from free list,
@@ -333,7 +332,7 @@  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){
+	if (elem->size - new_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);
 		split_pt = RTE_PTR_ALIGN_CEIL(split_pt, RTE_CACHE_LINE_SIZE);