This is something we encountered while working in an OpenShift
environment with SELinux enabled.
In this environment, a DPDK application could create/write to hugepage
files but removing them was refused.
This resulted in dirty files being reused when starting a new DPDK
application and triggered random crashes / erratic behavior.
Getting a SELinux setup can be a challenge, and even more if you add
containers to the picture :-).
So here is a reproducer for the interested testers:
# # First run is fine
# LD_PRELOAD=libwrap.so dpdk-testpmd -w 0000:01:00.0 -- -i
[...]
Configuring Port 0 (socket 0)
Port 0: 24:6E:96:3C:52:D8
Checking link statuses...
Done
testpmd>
# # Second run we have dirty memory
# LD_PRELOAD=libwrap.so dpdk-testpmd -w 0000:01:00.0 -- -i
[...]
### refused unlinkat for rtemap_0
[...]
Port 0 is now not stopped
Please stop the ports first
Done
testpmd>
Removing hugepage files is done in multiple places and the memory
allocation code is complex.
This fix tries to do the minimum and avoids touching other paths.
If trying to remove the hugepage file before allocating a page fails,
the error is reported to the caller and the user will see a memory
allocation error log.
Fixes: 582bed1e1d1d ("mem: support mapping hugepages at runtime") Cc: stable@dpdk.org Signed-off-by: David Marchand <david.marchand@redhat.com> Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>