From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary
 hugepage zero-filling
Date: Sun, 22 Nov 2015 22:52:20 -0800
Message-ID: <20151122225220.1fd15ba8@xeon-e3>
References: <1447817231-10510-1-git-send-email-zhihong.wang@intel.com>
 <1447817231-10510-3-git-send-email-zhihong.wang@intel.com>
 <B27915DBBA3421428155699D51E4CFE2023BE52A@IRSMSX103.ger.corp.intel.com>
 <8F6C2BD409508844A0EFC19955BE094183467C@SHSMSX152.ccr.corp.intel.com>
 <C37D651A908B024F974696C65296B57B4B198CF8@SHSMSX101.ccr.corp.intel.com>
 <564D930C.7060108@intel.com>
 <C37D651A908B024F974696C65296B57B4B1A6CFF@SHSMSX101.ccr.corp.intel.com>
 <20151122200743.34511547@xeon-e3>
 <C37D651A908B024F974696C65296B57B4B1A701B@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: "dev@dpdk.org" <dev@dpdk.org>
To: "Xie, Huawei" <huawei.xie@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com
 [209.85.220.45]) by dpdk.org (Postfix) with ESMTP id B6D748E80
 for <dev@dpdk.org>; Mon, 23 Nov 2015 07:52:11 +0100 (CET)
Received: by pabfh17 with SMTP id fh17so187498617pab.0
 for <dev@dpdk.org>; Sun, 22 Nov 2015 22:52:11 -0800 (PST)
In-Reply-To: <C37D651A908B024F974696C65296B57B4B1A701B@SHSMSX101.ccr.corp.intel.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Mon, 23 Nov 2015 05:05:21 +0000
"Xie, Huawei" <huawei.xie@intel.com> wrote:

> On 11/23/2015 12:07 PM, Stephen Hemminger wrote:
> > On Mon, 23 Nov 2015 03:46:31 +0000
> > "Xie, Huawei" <huawei.xie@intel.com> wrote:
> >
> >>> Why cannot we rely on the kernel zeroing the memory ?
> >>> If that behavior were to change, then we can zero out the memory
> >>> ourselves.  
> >> It is undocumented kernel behavior. My opinion is if not a big burden,
> >> zero out the needed memory ourselves, otherwise resort to this kernel
> >> behavior.
> > Really, I think it is more an oversight of missing documentation,
> > the kernel has always (and will continue) to zero out memory that is given
> > to a process. If it didn't it would be a massive security hole.
> Agree. I believe this behavior will not change in future. For the
> security issue, kernel could also set all bits like to 1. Just wonder if
> this is best practice and whether there are other user space programs
> rely on this behavior.
> 

Glibc almost certainly depends on this, because heap is grown by mmaping addtional
memory.