The __specialfd() system call is good to know about, but on its own doesn't provide a way to atomically create a configured jail with its lifetime tied to the file descriptor unlike passing a negative integer as "desc" argument to jail_set. There would either be a window where the jail would exist without a file descriptor associated with it which would reintroduce races and resource leak or the file descriptor has to start out unattached to a jail and be passed to the jail_set(JAIL_CREATE) call. The later design choice would get rid of the awkwardness of (ab-)using negative file descriptor numbers to request a file descriptor via an in-out parameter.

In D43696#996669, @dvl wrote:

I read the description, but I'm still not sure how a jail descriptor would be used. How about some pseudo-code, to illustrate the concept please?

In D41318#980524, @pauamma_gundo.com wrote:

No manual page to review, yet manpages is a group reviewer. Did a file get accidentally left out?

Is there enough space in the message to help users by giving them a reference to the new interface to express the same configuration and what form of reference would work well for this?

Good catch.

The interface name restriction function is a judgment call restricting users from creating problematic (for shell scripts) interface names. Applying the same restrictions to existing services like netif and routing could break (partly) working configurations.

In D40377#922101, @nyan_myuji.xyz wrote:

In D40377#922083, @crest_freebsd_rlwinm.de wrote:

The jail_name variable must be initialised to NULL. This should be done through an explicit char * jail_name = NULL; in line 101 of route.c.

Static storage are always initialized to 0/NULL by C standard.

The jail_name variable must be initialised to NULL. This should be done through an explicit char * jail_name = NULL; in line 101 of route.c.

It reads to me like initialising jail_name to NULL and replacing if (usejail) with if (jail_name != NULL) would make the usejail variable superfluous. Splitting a pointer and its validity into two variables like this (jail_name and usejail) introduces the potential for contradiction if only one of the two is updated. If this split is required for something I would like to see them stored together in a struct { char *, bool } instead of destructured into two variables.

Just a small nitpick: I would prefer a macro #define MAX_INCLUDE_DEPTH 32 or constant static const unsigned int max_include_depth = 32; somewhere above the include_config() in config.c instead of the literal to improve readability.

The jail(8) man page needs to be updated to reflect the new -F flag.

What is gained by having PID 1 acquire sub-reaper status given that it's the reaper? What are the expected semantics for proctl(PROC_REAP_ACQUIRE) in PID 1? Would it be enough to wrap the procctl(…) call with if ( getpid() != 1 ) { … } or is there more to this?

This change has been blamed to cause kernel panics on the FreeBSD current mailing list: https://lists.freebsd.org/archives/freebsd-current/2023-March/003381.html. It's been reported that reverting commit 0b56641cfcda30d06243223f37781ccc18455bef allows starting jails without triggering the observed kernel panic.

In D28199#636696, @rew wrote:

bhyve/ipc: use SOCK_DGRAM

• use SOCK_DGRAM instead of SOCK_STREAM
• have bhyvectl(8) share ipc.h from bhyve(8)
• fix naming semantics of MAX_SNAPSHOT_VMNAME, now called MAX_SNAPSHOT_FILENAME.

Previously, snapshot.h and bhyvectl.c each had their own
#define MAX_VMNAME 100, this is now shared at vmmapi.h - the
value has also been changed to 89. It's a limitation for the
unix domain socket path as constrained by SUNPATHLEN (104).
The prefix for the socket path is BHYVE_RUN_DIR, which by default
is '/var/run/bhyve/' (15). 104-15 = 89.