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: [dpdk-dev] [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
next reply other threads:[~2018-07-19 9:43 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 ` 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).