Page MenuHomeFreeBSD

kern: allow kern_shm_open2 of an anonymous preconstructed shmfd
ClosedPublic

Authored by kevans on Jul 16 2025, 4:50 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Oct 12, 12:37 AM
Unknown Object (File)
Sun, Oct 12, 12:37 AM
Unknown Object (File)
Sun, Oct 12, 12:37 AM
Unknown Object (File)
Sat, Oct 11, 3:04 PM
Unknown Object (File)
Sep 15 2025, 8:14 AM
Unknown Object (File)
Sep 4 2025, 9:22 PM
Unknown Object (File)
Sep 4 2025, 6:12 PM
Unknown Object (File)
Aug 26 2025, 2:03 AM
Subscribers

Details

Summary

The motivation here is for future changes to the coredump code to be able to
build up a coredump into a shmfd instead of a vnode, which then gets tapped
out to userland via a character device. This also opens up the possibility
that it's useful for the kernel to be able to construct a shmfd and pass it
out to a process that shouldn't need to write to it.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Still want to see any caller with shmfd != NULL

This revision is now accepted and ready to land.Jul 16 2025, 5:07 AM
In D51336#1172500, @kib wrote:

Still want to see any caller with shmfd != NULL

I do this here, specifically: https://git.kevans.dev/kevans/ucored/src/branch/wip/kmod/kmod/coredump_ucored.c#L117

That shmfd is populated down in the coredumper it installs. I suspect I'm going to play with the interface a little bit as far as how userspace actually receives these new fds, but I don't anticipate much change in the parts relevant to this review. My current plan is to try and get the interfaces I need into 15.0 (this stack of 3 is sufficient), then iterate on it a bit in ports. I think ucored(8) and the associated kmod would eventually be a good addition to consider for base as it'll add significant flexibility to what one can do with these things (to include piping them to some command, which is native functionality to a Linux kernel but more complicated than I care to implement).