Re: Is it valid to combine CTLFLAG_TUN with CTLFLAG_VNET ?

From: Zhenlei Huang <zlei_at_FreeBSD.org>
Date: Wed, 19 Apr 2023 02:31:42 UTC

> On Apr 6, 2023, at 3:56 AM, Hans Petter Selasky <hps@selasky.org> wrote:
> 
> On 4/5/23 21:44, Hans Petter Selasky wrote:
>> On 4/5/23 20:23, Gleb Smirnoff wrote:
>>> What if we remove the CTLFLAG_VNET check from the code you posted above?
>>> I don't see anything going wrong, rather going right 😄
>>> 
>>> CTLFLAG_VNET will not mask away CTLFLAG_TUN.
>> Hi Gleb,
>> It's possible to bypass that check, but some work needs to be done first. Then all jails created, will also start from those sysctl tunable values.
>> The problem is, where does the VNET base pointer come from?
>> Especially those static sysctl's. You would need to make some design there I guess and look at the SYSINIT() order. When are SYSINIT's filled with tunable data's. And when is the default VNET created.
>> Because the data pointer passed to the register sysctl function is simply an offset pointer into a malloc'ed structure.
>> --HPS
> 
> Hi Zhenlei,
> 
> Feel free to work on this, and add me as a reviewer and complete phase two of:
> 
>> commit 3da1cf1e88f8448bb10c5f778ab56ff65c7a6938
>> Author: Hans Petter Selasky <hselasky@FreeBSD.org>
>> Date:   Fri Jun 27 16:33:43 2014 +0000
>>    Extend the meaning of the CTLFLAG_TUN flag to automatically check if
>>    there is an environment variable which shall initialize the SYSCTL
>>    during early boot. This works for all SYSCTL types both statically and
>>    dynamically created ones, except for the SYSCTL NODE type and SYSCTLs
>>    which belong to VNETs. A new flag, CTLFLAG_NOFETCH, has been added to
> 
> --HPS

Posted to https://reviews.freebsd.org/D39638 <https://reviews.freebsd.org/D39638> 

CC freebsd-current if some people are interested in the fix.

Best regards,
Zhenlei