From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id BA487A0543; Sat, 27 Aug 2022 15:31:32 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5D88440DF7; Sat, 27 Aug 2022 15:31:32 +0200 (CEST) Received: from out162-62-58-216.mail.qq.com (out162-62-58-216.mail.qq.com [162.62.58.216]) by mails.dpdk.org (Postfix) with ESMTP id 83D7D40696 for ; Sat, 27 Aug 2022 15:31:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201512; t=1661607087; bh=lcp2JYobdyBm0e8lnuLqAjC2SXLdgiBY8/84wTcypwg=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=U9orVGM5DpAojrSxvlTVzGwvhxgrHkH5zBUPGWJrE9ZAgv0tSTkfJ/IAPhfxowzrD VR3AK1FxgwuHOxAuJkoV4gwMRw26QnJq489XU0D51xKUO4LouYHYLCZZzQ8K1zv6E2 gcbE9z57kmpwpCAya+HHieCDAJSt7ZojizzRJlek= Received: from vscode ([218.88.39.146]) by newxmesmtplogicsvrsza7.qq.com (NewEsmtp) with SMTP id 7CE888BA; Sat, 27 Aug 2022 21:31:14 +0800 X-QQ-mid: xmsmtpt1661607074tqwbdn05i Message-ID: X-QQ-XMAILINFO: NC/J3CrDtaBbM8O+gfjYMF+0baol69wqAwnuth+jWhcVcZMWgGcvw58jH/PiYk W/NaafzjkveBFJNGMuVZzFTirFCmVsVDT6jAgH2pEqvGDPZV4uKyS3D44C0TVkQ0ufXd3l60dAX2 3QrvBZyRrwhAUai4qT89KUtPdUJRszqTOYS48vQOlk7ztjgk8FTOUmk8MRWYB+atYmrsigGyLKI8 8PZZYQ5k9N4jAi0hi8vTtKJKO0ib63RnqoOgJ5xACGcFf/IT1/hnwK6KK/OZp6Jl9ZQPe4HKu4Oj JP9hh61pPgjgCe6G3ZRfkqLVWcb2wLXiOK8Pb/mBCgoCapubEcPGSozsS3+QQxbrHfL1ORhmUVmz 8Na3uPkQoWe0XbPjIyQesYSEAQwnl8lYRaZPYczkSJAF4aUqGpn0raAKUVkSzYLLmLCTXpfEW51g 3L8XF9PdTcleLRvStbAl0zLr8Y5De7MAy2Kv/3Bil9vjp1q3nTr1Wx+ik8GGH6/bo5nwwX3de97R Y+1vTSLvr8y3obz8TBfVNRCi90Avo0NcyumIfAOLkbQK5DRr5TQp4obxJ+r39fxL44NYka8ngh9v 3YAxxP0Tj9aujG7jBCh/uxVIl8t4R+1qIYA5IVrrfDPdqBPdl1EtC9TamcQdREhrI3/7SVKNS5z5 J53KY1FIa9ZthOWjx5rB4UwmF+sNnR15bh/e80i2FDMfbAM2FUhPxq113ziE4avN/fE1nBrPc3VM ty8P+LO3WoZ1mUnb6yL/EeB3FJdY+RQuWYJjM/vHG2iP1lyr9GWEEKVxVYoPoOwO5Eh5ugU1nLum pad3xnihnr4RCmXGIpQpVZDUhRWcMLybqwJM3PcBmy5tz5zHz5ZIVEr2qgtv7/aS72wQs3+VLdT4 q/AK8y6NnC5BRdnN3oVH6VCr0HEqfEh/yMcHpKxJxiRW+DMgwnh4Pfp3zAM4IH61JWPpMSHF5TXr ykiqOeLJUEu5f7O8HKiS4Q2cs0fj+0 Date: Sat, 27 Aug 2022 13:31:14 +0000 From: lic121 To: Dmitry Kozlyuk Cc: dev@dpdk.org, lic121 Subject: Re: [PATCH] eal: zero out new added memory X-OQ-MSGID: <20220827133114.GA26796@vscode> References: <20220827125750.291dd7d1@sovereign> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220827125750.291dd7d1@sovereign> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Sat, Aug 27, 2022 at 12:57:50PM +0300, Dmitry Kozlyuk wrote: > 2022-08-27 09:25 (UTC+0000), chengtcli@qq.com: > > From: lic121 > > > > When RTE_MALLOC_DEBUG not configured, rte_zmalloc_socket() doens't > > zero oute allocaed memory. Because memory are zeroed out when free > > in malloc_elem_free(). But seems the initial allocated memory is > > not zeroed out as expected. > > > > This patch zero out initial allocated memory in > > malloc_heap_add_memory(). > > > > With dpdk 20.11.5, "QLogic Corp. FastLinQ QL41000" probe triggers > > this problem. > > ``` > > Stack trace of thread 412780: > > #0 0x0000000000e5fb99 ecore_int_igu_read_cam (dpdk-testpmd) > > #1 0x0000000000e4df54 ecore_get_hw_info (dpdk-testpmd) > > #2 0x0000000000e504aa ecore_hw_prepare (dpdk-testpmd) > > #3 0x0000000000e8a7ca qed_probe (dpdk-testpmd) > > #4 0x0000000000e83c59 qede_common_dev_init (dpdk-testpmd) > > #5 0x0000000000e84c8e qede_eth_dev_init (dpdk-testpmd) > > #6 0x00000000009dd5a7 rte_pci_probe_one_driver (dpdk-testpmd) > > #7 0x00000000009734e3 rte_bus_probe (dpdk-testpmd) > > #8 0x00000000009933bd rte_eal_init (dpdk-testpmd) > > #9 0x000000000041768f main (dpdk-testpmd) > > #10 0x00007f41a7001b17 __libc_start_main (libc.so.6) > > #11 0x000000000067e34a _start (dpdk-testpmd) > > ``` > > > > Signed-off-by: lic121 > > --- > > lib/librte_eal/common/malloc_heap.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/lib/librte_eal/common/malloc_heap.c b/lib/librte_eal/common/malloc_heap.c > > index f4e20ea..1607401 100644 > > --- a/lib/librte_eal/common/malloc_heap.c > > +++ b/lib/librte_eal/common/malloc_heap.c > > @@ -96,11 +96,19 @@ > > void *start, size_t len) > > { > > struct malloc_elem *elem = start; > > + void *ptr; > > + size_t data_len > > + > > > > malloc_elem_init(elem, heap, msl, len, elem, len); > > > > malloc_elem_insert(elem); > > > > + /* Zero out new added memory. */ > > + *ptr = RTE_PTR_ADD(elem, MALLOC_ELEM_HEADER_LEN); > > + data_len = elem->size - MALLOC_ELEM_OVERHEAD; > > + memset(ptr, 0, data_len); > > + > > elem = malloc_elem_join_adjacent_free(elem); > > > > malloc_elem_free_list_insert(elem); > > Hi, > > The kernel ensures that the newly mapped memory is zeroed, > and DPDK ensures that files in hugetlbfs are not re-mapped. > What makes you think that it is not zeroed? > Were you able to catch [start; start+len) contain non-zero bytes > at the start of this function? > If so, is it system memory (not an external heap)? > If so, what is the CPU, kernel, any custom settings? > > Can it be the PMD or the app that uses rte_malloc instead of rte_zmalloc? > > This patch cannot be accepted as-is anyway: > 1. It zeroes memory even if the code was called not via rte_zmalloc(). > 2. It leads to zeroing on both alloc and free, which is suboptimal. Hi Dmitry, thanks for the review. In rte_eth_dev_pci_allocate(), imediately after rte_zmalloc_socket()[1] I printed the content in gdb. It's not zero. print ((struct qede_dev *)(eth_dev->data->dev_private))->edev->p_iov_info cpu: Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz kernel: 4.19.90-2102 [1] https://github.com/DPDK/dpdk/blob/v20.11/lib/librte_ethdev/rte_ethdev_pci.h#L91-L93