On Tue, Aug 11, 2026 at 09:39:12PM +0200, Jann Horn wrote: > 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
That would be the most straightforward use-case, yes. > 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)? I'm not sure about that. I think it's writing it to disk and then parsing it. But it also wranges it into a socket to forward to containers or services. Note that systemd has a pull request for the coredump socket up: https://github.com/systemd/systemd/pull/43330 This should kill the usermodehelper soon on kernels that support the socket. > Anyway, I've looked through your code and it does look fine to me. Thanks.
