On Tue, Aug 11, 2026 at 9:07 PM Jann Horn <[email protected]> wrote: > 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.
I also wonder what userspace actually does with this data - does userspace just want to write it to disk, potentially after compressing it? Or does userspace actually do some fancy parsing of the data stream to extract stack memory or something like that? Or does userspace buffer the whole thing into RAM and then process it from there (it kinda looks like systemd tries to do that but I might be reading this wrong)? Anyway, I've looked through your code and it does look fine to me.
