On Wed, Dec 18, 2024 at 11:05:46AM +0800, Zhenlei Huang wrote: > > > > On Dec 18, 2024, at 5:19 AM, Mark Johnston <[email protected]> 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. > > For current/15, it is actually doable since my previous work [1] and [2]. > > A usage example is the test plan in https://reviews.freebsd.org/D41825 > <https://reviews.freebsd.org/D41825> . > > For short, `kenv some.kenv=foo`, and then create vnet jail, `jail -c xxx > persist` .
Oh nice, I didn't know about that. > Those commits are not MFCed to stable/14 and stable/13, as I'm not satisfied > with the implementation. The current implementation is somewhat hacky > and I planed to re-work it. I think it's not quite enough for what I want to do. My main use-case is the regression test suite, which I typically run in parallel, so there's lots of concurrent jail creation and destruction. Some of those jail creation operations may want to set kenv values. Modifying the kenv is a global operation, so I can't do that from concurrent test runners. > > 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. > > > > 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. > > That is per-jail kenv, quite close to my working copy. You mean, you have some out-of-tree work in progress? > > 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. > > > > Best regards, > Zhenlei >
