RE: Including contigmem in core dumps

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Tuesday, 22 October 2024 17.39
> 
> On Tue, 22 Oct 2024 17:47:11 +0300
> Dmitry Kozlyuk <dmitry.kozliuk@gmail.com> wrote:
> 
> > 2024-10-22 07:41 (UTC-0500), Lewis Donzis:
> > > I've been wondering why we exclude memory allocated by
> > > eal_get_virtual_area() from core dumps? (More specifically, it
> calls
> > > eal_mem_set_dump() to call madvise() to disable core dumps from the
> > > allocated region.)
> > >
> > > On many occasions, when debugging after a crash, it would have been
> very
> > > convenient to be able to see the contents of an mbuf or other
> object
> > > allocated in contigmem space. And we often avoid using the rte
> memory
> > > allocator just because of this.
> > >
> > > Is there any reason for this, or could it perhaps be a compile-time
> > > configuration option not to call madvise()?
> >
> > The commit that originally added madvise() argued that dumping
> everything
> > ended up in coredumps with "useless" data [non-mapped or unused
> pages]:
> >
> >
> http://git.dpdk.org/dpdk/commit/?id=d72e4042c5ebda7af81448b387af8218136
> 402d0
> >
> > Dumping mapped pages sounds reasonable in many cases.
> > Not in all cases admittedly:
> > - legacy memory mode mapping a lot of pages that are not (yet) used;
> > - if packet data is confidential while the app is not.
> >
> > The option to dump or not can easily be a runtime one.
> > The safe default however seems to be "off".

Please feel free to submit a patch adding an EAL command line parameter to control core dump.

> >
> > In dynamic memory node (not FreeSBD, unfortunately)
> > rte_mem_event_callback-register() may be used to call madvise().
> > Maybe DPDK should allow such callbacks in any mode
> > and invoke them during initialization to make the above solution
> universal.
> 
> It is not unusual to have 2 or 4 Gigabytes of huge pages mapped.
> Many embedded systems do not have 6G of extra storage available for a
> single core
> dump, not to mention multiples. Plus any storage can be really slow on
> embedded
> systems.
> 
> And the common scenario on Linux is to use systemd to capture and
> compress
> core dumps.