On Thu, Dec 19, 2024 at 11:07:09AM +0800, Zhenlei Huang wrote: > > > > On Dec 19, 2024, at 12:43 AM, Mark Johnston <ma...@freebsd.org> wrote: > > > > On Wed, Dec 18, 2024 at 11:05:46AM +0800, Zhenlei Huang wrote: > >> > >> > >>> On Dec 18, 2024, at 5:19 AM, Mark Johnston <ma...@freebsd.org > >>> <mailto:ma...@freebsd.org>> 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><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? > > Yes. I'll publish it when ready. Recently busy working on SYSINIT stuff.
Awesome. Please let me know if I can help review or test. > The idea (per-vnet kenv) came when I was working on vnet tunables feature. > > I have ever mentioned this in D46653 [1], but been ignored. I think you hit > this once again :) Oops, I'm sorry Zhenlei, I completely missed that. :( > 1. https://reviews.freebsd.org/D46653 > > > > >>> 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 > > >
