On Tue, Dec 17, 2024 at 10:41:15PM +0100, Kristof Provost wrote: > On 17 Dec 2024, at 22:19, Mark Johnston wrote: > > We have a number of sysctls which are defined as tunables, whose values > > cannot be changed after boot. Some of these sysctls, such as net.fibs, > > are per-VNET so could in principle be changed at jail creation time. > > I'd find it useful to be able to pass a set of tunables to jail_set(2), > > so that corresponding VNET jail has tunables set to the specified > > values. For instance, it'd be useful in test suites where I want to > > exercise the network stack with different VNET sysctl settings, without > > having to configure the test runner at boot time. > > > There are a number of such cases. net.fibs is the obvious example, but > there’s also net.inet.ip.fw.default_to_accept and net.pf.default_to_drop.
I'm also adding some more tunables and would like to add test cases for non-default values of those tunables. It's straightforward enough for me to ensure that they're set properly in my test environment, but upstream CIs probably wouldn't go that far. And, if one wants to test both the default and non-default cases today, a reboot is needed. > > I think the implementation would involve passing an environment to > > vnet_alloc(), which would copy the parent VNET context and then iterate > > over all VNET tunables in the system, invoking > > sysctl_load_tunable_by_oid_locked() in such a way that the custom > > environment is used to update the tunable's value. > > > > Is there already some way to do what I want? If not, is there some > > reason we shouldn't implement this feature? Are there examples of VNET > > tunables for which it'd be unsafe to have values differing from the > > parent VNET? One can print a list of such variables with "sysctl > > -aVNT"; the list is pretty short and I don't see many obvious problems > > with allowing them to be modified. > > I’m not aware of any where it’d be unsafe. Most of them are tuneables because > they’d be annoying to make run-time configurable. (e.g. > net.pf.states_hashsize would involve allocating a new hash table and > re-hashing existing states into it. It’s possible, but to do it without > freezing traffic for an extended period would be difficult.) I do see one wrinkle: when an interface is moved into a jail with net.fibs > 1 and assigned to a FIB that's invalid in the host, we need to somehow reset the interface FIB when the interface is moved back. I suspect it's fine to just reset the interface FIB to 0 when moving back, and we should probably be doing that anyway. Maybe we are already, but I don't see it. > Stuff like that will just work when set for a new vnet. I like this idea. > > Best regards, > Kristof
