Instead of using IS_DEFAULT_VNET() in the vnet
initialization function, do the prison0 only initialization
in a separate SYSINIT() function.
Details
Tested on a system with nfsd(8) and friends running
both inside prisons and on prison0.
There wre printf's in the initialization functions, to see
that the SYSINIT() one was executed once and the VNET_SYSINIT()
one was executed for all prisons.
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Leaving both vnet init and global init as SI_SUB_VNET_DONE, SI_ORDER_ANY doesn't guarantee that the later runs earlier than the former. Although it seems safe today as vnet init doesn't grab the sx(9), imho, better make it correct and establish ordering. The most quick fix would be to set global init to SI_SUB_VNET_DONE, SI_ORDER_FIRST and vnet to SI_SUB_VNET_DONE, SI_ORDER_LAST. A more profound fix would be to think where rpc(9) belongs to in the whole network startup. SI_SUB_VNET_DONE might be too late. I don't know if any other subsystem may call into rpc(9) during boot, just guessing.
This version changes the subsystem for the
SYSINIT/SYSUNINIT macros to SI_SUB_VFS,
which is what is already used for the other
kgssapi SYSINIT.
(This code is a part of the kgssapi.ko module.)
As glebius@ noted, order did not currently
matter, but might matter in the future.