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 21216A0555; Sat, 27 Aug 2022 16:56:59 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BDDD640DF7; Sat, 27 Aug 2022 16:56:58 +0200 (CEST) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by mails.dpdk.org (Postfix) with ESMTP id D65CC40696 for ; Sat, 27 Aug 2022 16:56:56 +0200 (CEST) Received: by mail-lf1-f54.google.com with SMTP id z6so5525077lfu.9 for ; Sat, 27 Aug 2022 07:56:56 -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=qXQdonM/dDJtWf317Z8tAFcteCQXOYI947B/vzqUhyE=; b=jh5JubkR4Y+/zLMRIsePHHJX8uhejo9436mA6EZ9C2+7gDdHLo51sheIE//gjPAe4o NzIbdDq0WCC9qqx/QT2pBNsxcEjSJtrjkZR0Cd5Y6IlXcl42mGBN/zeCfzft2XCaLVKJ be0SbkxggXG4odMMVPjRHJiHiqqTIq685Tr6yjvRqcf3aTv0CxGoLW1OjCmz0mPzNmTR LI50eUTjNwwnC7n2YZ6CwNLmPwWmvNoh3VIet7eoEg/voCdDu4G36O3gue6jVPdtOF3j gJljz/GfacpqxWT58yByeU2BwseWKvUTQHpsL+LfMTyXw3bLj2Ql9drEWNMmZfFEIrgq uFQg== 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=qXQdonM/dDJtWf317Z8tAFcteCQXOYI947B/vzqUhyE=; b=wyYPK5rg7Srx3k6OCCKBmlMRNPk3f2jQ0iZgObS5eoepfA9fj2AhCzQ3FOI83sVQod QgzZUVxnpS9dmtiJKHx2aIpCeBLIKSNUZxd+HJfXkbJHvDbT8Ob3TWAB9fSXEFPbtkzR RPr4kw5njUKgoTPAKlP7lE2Z4lUJMtX1hsbP8qYJTrmMikbbsn+No9PpLHufBo1K9WR3 pyfiJDg4VDAErlFhYRLr9f6EAcJTZrrWhLv2QQgvwsrx/mbn4Wa7Neg6FsSgHS/2+66V Vavg3We/FhGQzyytIW9mBpFNAy3f7NKPQYyF+QBJV4yCySLq7hxT3C++3S4uwIPOnHTP f+xg== X-Gm-Message-State: ACgBeo0FTezLzuMj/xnkImzMHLOgNgjnswmCIVq9TpwFgBWtCQt9c3bR b7LVjvDLeLtoHsD0XwdUwQQ= X-Google-Smtp-Source: AA6agR4SrJUjSDi7MTnFrA5Q4wRvnp8IuFvHO+Wz42zMi52z5HqXy0gpYh+jCDuJe6V+3U9etWvPWQ== X-Received: by 2002:a05:6512:3905:b0:493:80a:46ba with SMTP id a5-20020a056512390500b00493080a46bamr3637194lfu.69.1661612216216; Sat, 27 Aug 2022 07:56:56 -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 t11-20020ac243ab000000b0048b03d1ca4asm685304lfl.161.2022.08.27.07.56.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 27 Aug 2022 07:56:55 -0700 (PDT) Date: Sat, 27 Aug 2022 17:56:54 +0300 From: Dmitry Kozlyuk To: lic121 Cc: dev@dpdk.org, lic121 Subject: Re: [PATCH] eal: zero out new added memory Message-ID: <20220827175654.7a167eaf@sovereign> In-Reply-To: References: <20220827125750.291dd7d1@sovereign> 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 13:31 (UTC+0000), lic121: > 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 Sorry, it seems that something is wrong with your debug. Your link is for 20.11.0. In 20.11.5 (apparently always) struct qede_dev::edev is not a pointer [2]. Even if it was, in zeroed memory it would be a NULL pointer, reading a member would give a random value at NULL + some offset. I suggest to print content of the allocated memory with rte_hexdump(). [2]: http://git.dpdk.org/dpdk-stable/tree/drivers/net/qede/qede_ethdev.h?h=v20.11.5#n223