DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
	sergio.gonzalez.monroy@intel.com, dev@dpdk.org
Subject: Re: [dpdk-dev] [RFC] mem: poison memory when freed
Date: Thu, 19 Jul 2018 10:46:59 +0100	[thread overview]
Message-ID: <20180719094659.GA23296@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <bc236193-a293-c475-6902-30bf14049ad9@intel.com>

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@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

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

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-18 21:44 Stephen Hemminger
2018-07-19  9:03 ` Burakov, Anatoly
2018-07-19  9:46   ` Bruce Richardson [this message]
2018-07-19  9:54 ` Burakov, Anatoly

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=20180719094659.GA23296@bricha3-MOBL.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=sergio.gonzalez.monroy@intel.com \
    --cc=stephen@networkplumber.org \
    /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).