malloc: don't skip pad on free
Checks
Commit Message
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(-)
Comments
On 19.07.2018 12:42, Anatoly Burakov wrote:
> 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>
Many thanks, the patch fixes the problem I've observed.
Tested-by: Andrew Rybchenko <arybchenko@solarflare.com>
19/07/2018 18:37, Andrew Rybchenko:
> On 19.07.2018 12:42, Anatoly Burakov wrote:
> > 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>
>
> Many thanks, the patch fixes the problem I've observed.
>
> Tested-by: Andrew Rybchenko <arybchenko@solarflare.com>
Applied, thanks
@@ -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);