On Tue, Aug 11, 2026 at 5:27 PM Christian Brauner <[email protected]> wrote: > A server that raises COREDUMP_HEADER in coredump_ack->mask doesn't get > the coredump as a plain byte stream but as a sequence of frames. Each > one a struct coredump_frame_header followed by what it describes. A data > frame carries its bytes. If a server also raises COREDUMP_SPARSE, zero > frames are sent for unpopulated mappings. They only indicate how many > zero bytes need to be written and to not include data. Reassembling the > frames gives back the same coredump. A debugger and everything else > still see an ordinary core file and nothing outside the coredump server > has to learn anything.
Hmm... I think what you're doing is probably the easiest way to do this in practice. I guess some design alternatives would be: 1. (overengineered, not generically useful enough): If the transport was a pipe (which already has the concept of different types of pipe buffers) instead of a unix domain socket, we could introduce a special representation for zero-filled pipe buffers and some API for receiving zeroed holes through lseek(pipefd, 0, SEEK_DATA), but that's probably not sufficiently useful for stuff other than core dumping to be worth the effort. 2. (somewhat overengineered) With some refactoring, we could maybe do something like /proc/kcore and create a seekable virtual coredump file that we send over the socket via SCM_RIGHTS? 3. We could leave the userspace memory dump out of the core dump data, and let userspace take care of filling out the memory contents using /proc/$pid/pagemap and /proc/$pid/mem? That would also avoid task switches and SKB allocations, and probably reduce the number of data copies involved in this by 1.
