[dpdk-dev] [RFC] mem: poison memory when freed

Bruce Richardson bruce.richardson at intel.com
Thu Jul 19 11:46:59 CEST 2018


On Thu, Jul 19, 2018 at 10:03:55AM +0100, Burakov, Anatoly wrote:
> On 18-Jul-18 10:44 PM, Stephen Hemminger wrote:
> > DPDK malloc library allows broken programs to work because
> > the semantics of zmalloc and malloc are the same.
> > 
> > This patch changes to a more secure model which will catch
> > (and crash) programs that reuse memory already freed.
> > 
> > This supersedes earlier changes to zero memory on free and
> > avoid zeroing memory in zmalloc.
> > 
> > Signed-off-by: Stephen Hemminger <stephen at networkplumber.org>
> > ---
> 
> I would be a bit wary of introducing this change without prior announcement.
> Currently, rte_malloc'd memory is semantically identical to zmalloc'd
> memory, which means there may be code that relies on this behavior, even
> though it's technically incorrect.
> 
> How about a deprecation notice, and do this in 18.11?
> 
The question I have is, how much is this going to slow down calls to
zmalloc, particularly those on application startup? The advantage of the
previous scheme was that for applications with large memory footprints, we
were able to give them their allocations quickly, and had no zeroing
overhead unless blocks of memory were continually being allocated and
freed. With this, the startup time of some apps could be badly impacted.
Perhaps we should make this a runtime debug option.

/Bruce


More information about the dev mailing list