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 6EEBAA04FD; Tue, 30 Aug 2022 03:11:43 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 49F0540F18; Tue, 30 Aug 2022 03:11:43 +0200 (CEST) Received: from out203-205-221-155.mail.qq.com (out203-205-221-155.mail.qq.com [203.205.221.155]) by mails.dpdk.org (Postfix) with ESMTP id E4F6F40F17 for ; Tue, 30 Aug 2022 03:11:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201512; t=1661821899; bh=u/J8CWDDbMmKFQrplrGIXP4BD0byYpHH9361sYUkyVg=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=aWsAoH7s1F/UYmdBr2VBP5Sf6W0IcyiFV6kI8jRecj5ram5jSyn20cv/VEkI6RPLB +Ltkk2KdQ6bOTJBoHQFV8hnzlW94n6MtGi8F0kzLVRnuh4IcAUMB15uV4CEgxb7e6u A71KpdXEQFAmRYP8mcRW9SM1ZYCZEc7L8zzcp+oc= Received: from vscode.7~ ([36.111.64.85]) by newxmesmtplogicsvrsza31.qq.com (NewEsmtp) with SMTP id 2D9BD436; Tue, 30 Aug 2022 09:11:25 +0800 X-QQ-mid: xmsmtpt1661821885t3r7qk0uj Message-ID: X-QQ-XMAILINFO: NY/MPejODIJVpVB+tVQu7/E74AxWltkoytUQ9tEagNKQePI0+0jnxvJiIB1Rvy mxyZ2nmhsw5Yv9IseYu3B1YOzzcEZ3lUaqH9oJnF0l7ETiJ2Yw6k/NYXoo4ny2KngtDx8yCH3QMK YmG1dUvzR8tXEPlJNWnyRyeRS1mExRkh6Jm5JAAqB9chbxv9mFgXNJB0xEJTD1zjwHwapS2o8z3M 8Vw2KLFYIMQRn5vnFCnOrl7End9/NmdTv4AxnGNBJzE062joY5cfvPLTUukaLnPqsyDT8AiI0woM YpY5vBJZg2LATZ3jlM2zZoFX3wIcwZJq11BuE3GWKR8K8OQ/u1Kun8dahNo1pEXV3Yfd4bhnpxQN IAIdYgFHG04la8zgFm3HRrgH0F/y/hyhR33Sn1UeF+EF9T8IQEvqzVGlxHjm2glUFf0L6vJDEULn 8/iE6kFwdBR1cGG9w2ESK6KFeb83DiqGUlOzBjMCBlHerGOLofUufG0obwuCW0HijdawRTCiWT5K upiBMbJP1mvwEsDdYEOBxejTSk6Fmoob+7kjvftbAPc2RH7DY3ppigA+lj75j/zYzjK7DtK7Ie4X sFgJ4i8KFqOYczEtounjOYTgKC0C0hpydRxFP5dlW8pJ0rcor1gLnXUxbHonE+yOUT7UkaqKE+A6 jbmGDjgflWjwimvL0pqTOIYI4kHDxmhIqjVjOp1A6q5hJlTguUn5k1bTA7QAcwu0qT3M4X9n3MvG sJVtNCeav9BugyDeit903iod9d7uYqZy/0TSjxotScgKZ5YfN//iNckV/zVfw0X1s8auZ1VLL43h HQl7b69stuAyoZylz6SLPSfRuxZ+lNUDPPD4NqeehO7R1PXiBx13L0O7Aqxv8tBFlNf3tzAS6zWs xxtNfwkomhbbKZQtfpdGfG6T1PxpvxoMAC59+PI1U9k+cHMMZ1RCTP59UnaZqaJg== Date: Tue, 30 Aug 2022 01:11:25 +0000 From: lic121 To: Dmitry Kozlyuk Cc: Morten =?iso-8859-1?Q?Br=F8rup?= , David Marchand , dev Subject: Re: [PATCH] eal: zero out new added memory X-OQ-MSGID: <20220830011125.GA1836@vscode.7~> References: <20220827125750.291dd7d1@sovereign> <20220827175654.7a167eaf@sovereign> <98CBD80474FA8B44BF855DF32C47DC35D872CC@smartserver.smartshare.dk> <20220829154925.6575540a@sovereign> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220829154925.6575540a@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 Mon, Aug 29, 2022 at 03:49:25PM +0300, Dmitry Kozlyuk wrote: > 2022-08-29 14:37 (UTC+0200), Morten Brørup: > > > From: David Marchand [mailto:david.marchand@redhat.com] > > > Sent: Monday, 29 August 2022 13.58 > > > > > > > > > > On Sat, Aug 27, 2022 at 12:57:50PM +0300, Dmitry Kozlyuk wrote: > > > > > > > > The kernel ensures that the newly mapped memory is zeroed, > > > > > > > > and DPDK ensures that files in hugetlbfs are not re-mapped. > > > > David, are you suggesting that this invariant - guaranteeing that DPDK memory is zeroed - was violated by SELinux in the SELinux/container issue you were tracking? > > > > If so, the method to ensure the invariant is faulty for SELinux. Assuming DPDK supports SELinux, this bug should be fixed. > > +1, I'd like to know more about that case. > > EAL checks the unlink() result, so if it fails, the allocation should fail > and the invariant should not be broken. > Code from 20.11.5: > > if (rte_eal_process_type() == RTE_PROC_PRIMARY && > unlink(path) == -1 && > errno != ENOENT) { > RTE_LOG(DEBUG, EAL, "%s(): could not remove '%s': %s\n", > __func__, path, strerror(errno)); > return -1; > } > > Can SELinux restriction result in errno == ENOENT? > I'd expect EPERM/EACCESS. Thanks for your info, the selinux is disabled on my server. Also I checked that the selinux fix is already in my dpdk. Could any other settings may cause dirty memory? If you can think of any thing related, I can have a try. BTW, this is my nic info: ``` Intel Corporation Ethernet Controller E810-XXV for SFP (rev 02) driver: ice version: 1.9.3 firmware-version: 2.30 0x80005d22 1.2877.0 expansion-rom-version: bus-info: 0000:3b:00.1 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes ```