> 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. 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 :) 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
