kern: abstract away the vnode coredumper to allow pluggable dumpers

The default and only stock coredumper will continue to be the
traditional vnode dumper, which will dump to a vnode and issue a dev

kern: abstract away the vnode coredumper to allow pluggable dumpers

The default and only stock coredumper will continue to be the
traditional vnode dumper, which will dump to a vnode and issue a devctl
notification. With this change, one can write a kmod that injects custom
handling of user coredumps that offers richer behavior, particularly in
case one wants to add more metadata than we can tap out via devd.

The main motivation here is to pave the way for my usercore daemon to be
able to reroute coredumps before they ever touch the disk. In some
cases they may be discarded and we can avoid the overhead of writing
anything, in others they allow us to capture coredumps that would be
written into an area that's transient in nature (e.g., kyua test work
directories) without having to do more tricks to keep those alive. My
WIP kmod writes the coredump into a shmfd instead of a vnode, then
installs that into ucored(8) with every read(2) of /dev/ucore. This
also allows me to capture more metadata reliably before the process and
jail disappear.

Reviewed by: kib (earlier version), markj
Differential Revision: https://reviews.freebsd.org/D51338

show more ...

kern: move the vnode user coredumper out into its own file

This more cleanly contains the bits that are specifically relevant to
dumping coredumps out to a vnode, which will make future changes a bi

kern: move the vnode user coredumper out into its own file

This more cleanly contains the bits that are specifically relevant to
dumping coredumps out to a vnode, which will make future changes a bit
easier to review. This also makes the scope of the relevant sysctls
easier to reason about in the process, as they're not visible outside of
the vnode dumper file -- this will mostly become relevant when we allow
pluggable dumpers.

While we're here, move all of the coredump-related stuff out into its
own kern_ucoredump.c and sys/ucoredump.h. We have enough that it's
useful to separate it out and de-clutter kern_sig.c and sys/exec.h a
bit.

Reviewed by: kib, markj (both earlier version)
Differential Revision: https://reviews.freebsd.org/D51349

show more ...

kern: abstract away the vnode coredumper to allow pluggable dumpers

The default and only stock coredumper will continue to be the
traditional vnode dumper, which will dump to a vnode and issue a dev

kern: abstract away the vnode coredumper to allow pluggable dumpers

The default and only stock coredumper will continue to be the
traditional vnode dumper, which will dump to a vnode and issue a devctl
notification. With this change, one can write a kmod that injects custom
handling of user coredumps that offers richer behavior, particularly in
case one wants to add more metadata than we can tap out via devd.

The main motivation here is to pave the way for my usercore daemon to be
able to reroute coredumps before they ever touch the disk. In some
cases they may be discarded and we can avoid the overhead of writing
anything, in others they allow us to capture coredumps that would be
written into an area that's transient in nature (e.g., kyua test work
directories) without having to do more tricks to keep those alive. My
WIP kmod writes the coredump into a shmfd instead of a vnode, then
installs that into ucored(8) with every read(2) of /dev/ucore. This
also allows me to capture more metadata reliably before the process and
jail disappear.

Reviewed by: kib (earlier version), markj
Differential Revision: https://reviews.freebsd.org/D51338

show more ...

kern: move the vnode user coredumper out into its own file

This more cleanly contains the bits that are specifically relevant to
dumping coredumps out to a vnode, which will make future changes a bi

kern: move the vnode user coredumper out into its own file

This more cleanly contains the bits that are specifically relevant to
dumping coredumps out to a vnode, which will make future changes a bit
easier to review. This also makes the scope of the relevant sysctls
easier to reason about in the process, as they're not visible outside of
the vnode dumper file -- this will mostly become relevant when we allow
pluggable dumpers.

While we're here, move all of the coredump-related stuff out into its
own kern_ucoredump.c and sys/ucoredump.h. We have enough that it's
useful to separate it out and de-clutter kern_sig.c and sys/exec.h a
bit.

Reviewed by: kib, markj (both earlier version)
Differential Revision: https://reviews.freebsd.org/D51349

show more ...

kern: abstract away the vnode coredumper to allow pluggable dumpers

The default and only stock coredumper will continue to be the
traditional vnode dumper, which will dump to a vnode and issue a dev

kern: abstract away the vnode coredumper to allow pluggable dumpers

The default and only stock coredumper will continue to be the
traditional vnode dumper, which will dump to a vnode and issue a devctl
notification. With this change, one can write a kmod that injects custom
handling of user coredumps that offers richer behavior, particularly in
case one wants to add more metadata than we can tap out via devd.

The main motivation here is to pave the way for my usercore daemon to be
able to reroute coredumps before they ever touch the disk. In some
cases they may be discarded and we can avoid the overhead of writing
anything, in others they allow us to capture coredumps that would be
written into an area that's transient in nature (e.g., kyua test work
directories) without having to do more tricks to keep those alive. My
WIP kmod writes the coredump into a shmfd instead of a vnode, then
installs that into ucored(8) with every read(2) of /dev/ucore. This
also allows me to capture more metadata reliably before the process and
jail disappear.

Reviewed by: kib (earlier version), markj
Differential Revision: https://reviews.freebsd.org/D51338

show more ...

kern: move the vnode user coredumper out into its own file

This more cleanly contains the bits that are specifically relevant to
dumping coredumps out to a vnode, which will make future changes a bi

kern: move the vnode user coredumper out into its own file

This more cleanly contains the bits that are specifically relevant to
dumping coredumps out to a vnode, which will make future changes a bit
easier to review. This also makes the scope of the relevant sysctls
easier to reason about in the process, as they're not visible outside of
the vnode dumper file -- this will mostly become relevant when we allow
pluggable dumpers.

While we're here, move all of the coredump-related stuff out into its
own kern_ucoredump.c and sys/ucoredump.h. We have enough that it's
useful to separate it out and de-clutter kern_sig.c and sys/exec.h a
bit.

Reviewed by: kib, markj (both earlier version)
Differential Revision: https://reviews.freebsd.org/D51349

show more ...