From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 7BF122C2F for ; Thu, 19 Jul 2018 11:47:05 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2018 02:47:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,374,1526367600"; d="scan'208";a="65840374" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.107]) by FMSMGA003.fm.intel.com with SMTP; 19 Jul 2018 02:47:01 -0700 Received: by (sSMTP sendmail emulation); Thu, 19 Jul 2018 10:47:00 +0100 Date: Thu, 19 Jul 2018 10:46:59 +0100 From: Bruce Richardson To: "Burakov, Anatoly" Cc: Stephen Hemminger , sergio.gonzalez.monroy@intel.com, dev@dpdk.org Message-ID: <20180719094659.GA23296@bricha3-MOBL.ger.corp.intel.com> References: <20180718214434.608-1-stephen@networkplumber.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.10.0 (2018-05-17) Subject: Re: [dpdk-dev] [RFC] mem: poison memory when freed X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 09:47:05 -0000 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 > > --- > > 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