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 C0546A04FD; Sat, 27 Aug 2022 11:57:54 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 682BC40DF7; Sat, 27 Aug 2022 11:57:54 +0200 (CEST) Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by mails.dpdk.org (Postfix) with ESMTP id 5843240696 for ; Sat, 27 Aug 2022 11:57:53 +0200 (CEST) Received: by mail-lf1-f43.google.com with SMTP id l8so4902893lfc.12 for ; Sat, 27 Aug 2022 02:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc; bh=IxuXPYN4a9RkSCZkUTqHsSM8CGCfszsKlG1Bf7WTl6o=; b=qpv+erl11avQLx4kGJHI/X42mm7Xxtwz5EyUmETn9FqHABwej1OERcs7O5aHkDgg5u Av5ZnZGs1dNz0nUgbdP5e2GZSX15Z7r/lFA6JZwGcWckeyEMf0/JLawBiAkTldiTMEgD 8u1r3nbXJbdDDDtdDx/Lmdu+Fa80ic+FIArfByKHCRKBOklIec77rhQLDoMuCUPexU5u cygGtOfgiA8KkxCayV2f1HNxIf2TRKUzoZHcZvyDZu9LEji3F/ras6TN1TQ84X9D3HpP 1/YbDurJ/QBWRgokcIvhk2bTvvthKW5IowTcyc8fxBxpi3CjFSHA5+NhSPdUfDxkl7X5 Yk4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=IxuXPYN4a9RkSCZkUTqHsSM8CGCfszsKlG1Bf7WTl6o=; b=DF1fPI5VRTADcPeeSvNn/D/SYEPSup+9OqcBGgLumIVrfpMix+hUO74kCa4K5vwMbt 9BA8uS5nbiAeCn6lyDjeQ1wTQkiIZ9jRiKlqnIK+Lm1W9V93F1tSUFGOm5B7kq7QfQwy lCLq6hq2Xx/r5EsqOtolIkdVYHYLIvoNHVn3KlvwsUn2QnFKyXicrTseY2TADRX7trND tt3F+z1qpBu/IebSLyoIe8QyzPoODwd73eoBIAvhJvnI2fzDIwq2v8nhBFSBh+no51IJ /1pRCJUEwfbMPrusTIHo37IKxLVF3q42/0HOpBeys/sQokCaGSC/EH+ue6NRpISJAizF WyrA== X-Gm-Message-State: ACgBeo2oKdxgMhp1iVdTHdi/0s/XbjRY2G9sSlp5mLibQukI27pXtfkq kvywNDRpfM3qlxZmDdsH9lM= X-Google-Smtp-Source: AA6agR7tn4QWLCeyiuvXxhg7UBrQ8Ep8Bvk+vxhr5lxg5KcifZUlW6LZ//rbR5yDr85ecCXYY4O/9Q== X-Received: by 2002:a05:6512:b08:b0:492:87ad:5f5c with SMTP id w8-20020a0565120b0800b0049287ad5f5cmr4056157lfu.293.1661594272771; Sat, 27 Aug 2022 02:57:52 -0700 (PDT) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id a4-20020ac25204000000b0048ac33f34d8sm611857lfl.289.2022.08.27.02.57.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 27 Aug 2022 02:57:52 -0700 (PDT) Date: Sat, 27 Aug 2022 12:57:50 +0300 From: Dmitry Kozlyuk To: chengtcli@qq.com Cc: dev@dpdk.org, lic121 Subject: Re: [PATCH] eal: zero out new added memory Message-ID: <20220827125750.291dd7d1@sovereign> In-Reply-To: References: X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 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.