[PATCH v1 6/6] eal: extend --huge-unlink for hugepage file reuse

[Thomas Monjalon]

17/01/2022 09:14, Dmitry Kozlyuk:
> Expose Linux EAL ability to reuse existing hugepage files
> via --huge-unlink=never switch.
> Default behavior is unchanged, it can also be specified
> using --huge-unlink=existing for consistency.
> Old --huge-unlink switch is kept,
> it is an alias for --huge-unlink=always.
> 
> Signed-off-by: Dmitry Kozlyuk <dkozlyuk at nvidia.com>
> ---
>  doc/guides/linux_gsg/linux_eal_parameters.rst | 21 ++++++++--
>  .../prog_guide/env_abstraction_layer.rst      |  9 +++++
>  doc/guides/rel_notes/release_22_03.rst        |  7 ++++
>  lib/eal/common/eal_common_options.c           | 39 +++++++++++++++++--
>  4 files changed, 69 insertions(+), 7 deletions(-)
> 
> diff --git a/doc/guides/linux_gsg/linux_eal_parameters.rst b/doc/guides/linux_gsg/linux_eal_parameters.rst
> index 74df2611b5..7586f15ce3 100644
> --- a/doc/guides/linux_gsg/linux_eal_parameters.rst
> +++ b/doc/guides/linux_gsg/linux_eal_parameters.rst
> @@ -84,10 +84,23 @@ Memory-related options
>      Use specified hugetlbfs directory instead of autodetected ones. This can be
>      a sub-directory within a hugetlbfs mountpoint.
>  
> -*   ``--huge-unlink``
> -
> -    Unlink hugepage files after creating them (implies no secondary process
> -    support).
> +*   ``--huge-unlink[=existing|always|never]``
> +
> +    No ``--huge-unlink`` option or ``--huge-unlink=existing`` is the default:
> +    existing hugepage files are removed and re-created
> +    to ensure the kernel clears the memory and prevents any data leaks.
> +
> +    With ``--huge-unlink`` (no value) or ``--huge-unlink=always``,
> +    hugepage files are also removed after creating them,
> +    so that the application leaves no files in hugetlbfs.
> +    This mode implies no multi-process support.
> +
> +    When ``--huge-unlink=never`` is specified, existing hugepage files
> +    are not removed either before or after mapping them.

One detail not clear: the second unlink is before or after mapping?

> +    This makes restart faster by saving time to clear memory at initialization,
> +    but it may slow down zeroed allocations later.
> +    Reused hugepages can contain data from previous processes that used them,
> +    which may be a security concern.

I absolutely love these options.
It keeps compability while making things consistent and understandable.

Acked-by: Thomas Monjalon <thomas at monjalon.net>