On 17-Sep-20 2:47 PM, David Marchand wrote:
On Fri, Sep 11, 2020 at 2:46 PM Burakov, Anatoly
<anatoly.bura...@intel.com> wrote:
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: sta...@dpdk.org
Signed-off-by: David Marchand <david.march...@redhat.com>
---
I believe only the primary will try to allocate new pages, but this only
covers the page-per-file scenario. There's also legacy mem option (which
would attempt to remove files prior to creating new ones - not sure if
it's refused in that case), and single file segments option (which will
mostly fallocate holes rather than delete files, but may still attempt
to delete files - by the way, how does fallocate work with SELinux?).
This issue should only concern part of the memory allocator that deals
with "named files" backed hugepages.
I would focus on the code relying on eal_get_hugefile_path() and I
agree I might have missed the legacy-mem part.
For anonymous hugepages this should not matter.
Anonymous hugepages shouldn't matter, yes, but single-file segments mode
does fallocate() and remove - you have the remove part covered, but i'm
just curious if fallocate() would also cause any issues with SELinux.
--
Thanks,
Anatoly
