All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anatoly Burakov <anatoly.burakov@intel.com>
To: dev@dpdk.org
Cc: arybchenko@solarflare.com, stephen@networkplumber.org,
	thomas@monjalon.net, stable@dpdk.org
Subject: [PATCH] malloc: don't skip pad on free
Date: Thu, 19 Jul 2018 10:42:46 +0100	[thread overview]
Message-ID: <038143a314345e9c5bf76b1287497a5c4c9f63ed.1531992860.git.anatoly.burakov@intel.com> (raw)

Previously, we were skipping erasing pad because we were
expecting it to be freed when we were merging adjacent
segments. However, if there were no adjacent segments to
merge, we would've skipped erasing the pad, leaving non-zero
memory in our free space.

Fix this by including pad in the erasing unconditionally.

Fixes: e43a9f52b7ff ("malloc: fix pad erasing")
Cc: stable@dpdk.org

Reported-by: Andrew Rybchenko <arybchenko@solarflare.com>

Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
---

Notes:
    I have confirmed the issue with unit tests - adding a simple zero-check
    function on alloc will throw errors when running malloc_autotest on
    latest master, but the errors go away once this patch is applied.
    
    Our unit test's zmalloc calls check if memory is not zero, but this
    condition is rare enough not to be triggered by it, and regular
    malloc calls aren't checked on zeroed out memory. The bulk of the
    malloc calls in the unit tests are malloc, not zmalloc, so pretty
    much all of the time the memory is not checked for being zero on
    alloc.

 lib/librte_eal/common/malloc_elem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/common/malloc_elem.c b/lib/librte_eal/common/malloc_elem.c
index efcb82677..e0a8ed15b 100644
--- a/lib/librte_eal/common/malloc_elem.c
+++ b/lib/librte_eal/common/malloc_elem.c
@@ -519,8 +519,8 @@ malloc_elem_free(struct malloc_elem *elem)
 	void *ptr;
 	size_t data_len;
 
-	ptr = RTE_PTR_ADD(elem, MALLOC_ELEM_HEADER_LEN + elem->pad);
-	data_len = elem->size - elem->pad - MALLOC_ELEM_OVERHEAD;
+	ptr = RTE_PTR_ADD(elem, MALLOC_ELEM_HEADER_LEN);
+	data_len = elem->size - MALLOC_ELEM_OVERHEAD;
 
 	elem = malloc_elem_join_adjacent_free(elem);
 
-- 
2.17.1

             reply	other threads:[~2018-07-19  9:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-19  9:42 Anatoly Burakov [this message]
2018-07-19 16:37 ` [PATCH] malloc: don't skip pad on free Andrew Rybchenko
2018-07-20  9:27   ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=038143a314345e9c5bf76b1287497a5c4c9f63ed.1531992860.git.anatoly.burakov@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=stable@dpdk.org \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.