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.march...@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 ```
