> From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Tuesday, 22 October 2024 17.39 > > On Tue, 22 Oct 2024 17:47:11 +0300 > Dmitry Kozlyuk <dmitry.kozl...@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.
