Re: [PATCH] eal: zero out new added memory

[lic121 <chengtcli@qq.com>]

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
```