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

[Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>]

2024-10-24 23:54 (UTC+0300), Dmitry Kozlyuk:
> 2024-10-24 09:38 (UTC-0700), Stephen Hemminger:
> > Having a process set a system global value like coredump_filter via an internal
> > call seems like a potential problem. What about other processes on the system?
> > It may not even be allowed if using a hardened kernel.
> > 
> > I would prefer that madvise() be used, and document the required change to
> > coredump_filter.  
> 
> /proc/self/coredump_filter affects only the process and its children.
> madvise() done on hugepages will be ignored unless this bit is set.
> So this must be done, and it seems convenient to require no user interaction.
> If changing /proc/self/coredump_filter is disallowed,
> EAL startup will fail and the user will have to go the way you described.
> So the current solution:
> - is convenient for a typical case
> - is still usable in a hypothetical hardening case
> 
> On FreeBSD, including hugepages in core dump will require a global setting.
> There I've been planning to go your way and have the user configure it,
> because it is impossible to restrict to one process.

On the second thought, why block or enforce anything at startup;
it is more flexible if we allow the user to enable dumping hugepages
at whatever moment they wish, including prior to startup.
This series would then become purely documentation for Linux
and similar + a bit of code for FreeBSD.