[PATCH] eal: support including mapped memory in core dump

[Morten Brørup]

> From: Dmitry Kozlyuk [mailto:dmitry.kozliuk at gmail.com]
> Sent: Thursday, 24 October 2024 01.19
> 
> Commit d72e4042c5eb ("mem: exclude unused memory from core dump")
> unconditionally excluded all hugepage memory managed by DPDK.
> The rationale was to avoid overly large core dumps
> generated from reserved (PROT_NONE) but not mapped memory.
> Mapped hugepages, however, may hold data useful for debugging,
> even if not being fully used and containing some garbage.
> Users may want to include those hugepages in core dump.
> 
> Add `--huge-dump` EAL command-line option to include in core dump
> all mapped hugepages and also non-hugepage memory
> allocated with `--no-huge` (as it substitutes for hugepages).

I agree with the behavior of also dumping --no-huge mapped.
Perhaps because of this, the option should be named differently; something like --dump-verbose, --dump-all, --dump-mapped.

> Using this option requires more disk storage for core dumps,
> and also may include sensitive data in core dump,
> which is why it must be explicitly enabled and a warning is printed.
> 
> Linux requires /proc/self/coredump_filter adjustment
> to include hugepages mapped with MAP_SHARED in core dump.
> Windows EAL requires no change since it automatically
> excludes reserved memory and includes committed memory.

The above O/S specific information should also be included as notes in the documentation.

> 
> Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk at gmail.com>
> ---
> Lewis, testing on FreeBSD would be appreciated.

If there are any notes about FreeBSD, like the notes about Linux and Windows above, it should also be included in the documentation.

> --- a/doc/guides/linux_gsg/eal_args.include.rst
> +++ b/doc/guides/linux_gsg/eal_args.include.rst
> @@ -122,6 +122,14 @@ Memory-related options
>      to system pthread stack size unless the optional size (in kbytes)
> is
>      specified.
> 
> +*   ``--huge-dump``
> +
> +    Include in code dump all hugepages mapped by DPDK either at
> startup or later,
> +    and ordirary pages mapped by DPDK at startup when ``--no-huge`` is
> given.
> +    Hugepages increase core dumps size roughly by the amount of memory
> used.
> +    Dumped memory often contains processed data, which may be
> sensitive.
> +    Primary and secondary processes can use this option independently.
> +

With O/S specific notes added to the documentation,
Acked-by: Morten Brørup <mb at smartsharesystems.com>