Re: Is it valid to combine CTLFLAG_TUN with CTLFLAG_VNET ?

On Wed, Apr 05, 2023 at 07:24:07PM +0200, Hans Petter Selasky wrote:
H> On 4/5/23 19:02, Zhenlei Huang wrote:
H> > While working on https://reviews.freebsd.org/D39375 I noticed some tunables
H> > have sysctl flags CTLFLAG_RWTUN | CTLFLAG_VNET .
H> > 
H> > CTLFLAG_RWTUN is defined as (CTLFLAG_RW | CTLFLAG_TUN) . The CTLFLAG_TUN is
H> > for loader tunable.
H> > 
H> > I expected those loader tunables will have correct value regardless the
H> > CTLFLAG_VNET flag but that is not true.
H> > 
H> > Steps to repeat:
H> > # echo "net.link.bridge.log_stp=1" >> /boot/loader.conf
H> > # reboot
H> > # kldload if_bridge
H> > # sysctl net.link.bridge.log_stp
H> > net.link.bridge.log_stp: 0
H> > 
H> > So is it valid to combine CTLFLAG_TUN with CTLFLAG_VNET ?
H> 
H> You can specify the flags together, but it results in nothing with 
H> regards to loading values from tunables:
H> 
H> >         if ((oidp->oid_kind & CTLTYPE) != CTLTYPE_NODE &&
H> > #ifdef VIMAGE
H> >             (oidp->oid_kind & CTLFLAG_VNET) == 0 &&
H> > #endif
H> >             (oidp->oid_kind & CTLFLAG_TUN) != 0 &&
H> >             (oidp->oid_kind & CTLFLAG_NOFETCH) == 0) {
H> >                 /* only fetch value once */
H> >                 oidp->oid_kind |= CTLFLAG_NOFETCH;
H> >                 /* try to fetch value from kernel environment */
H> >                 sysctl_load_tunable_by_oid_locked(oidp);
H> >         }
H> 
H> If I'm not mistaken, I put the check there, when I added support for 
H> loading default values for sysctls via /boot/loader.conf and kenv to 
H> avoid undefined behaviour. Before that CTLFLAG_TUN existed, but was 
H> coupled with manual variable loading via the kernel environment 
H> functions. Only functions that need values loaded very early during 
H> boot, still use TUNABLE_XXX_FETCH() and the alike.
H> 
H> git blame sys/kern_sysctl.c
H> 
H> I guess that for VNETs you'll have to keep on using TUNABLE_XXX_FETCH() 
H> to get appropriate values into the sysctls . This discussion could also 
H> continue on current@freebsd.org .

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.

-- 
Gleb Smirnoff