Re: panic/hang with new WITNESS and MAC_PORTACL

On Tue, 2 Mar 2004, John Baldwin wrote:

> > panic: mtx_lock_spin() of sleep mutex (null) _at_
> > ../../../kern/subr_sleepqueue.c:193 at line 352 in file
> > ../../../kern/kern_mutex.c
> > Debugger("panic")
> > Stopped at      Debugger+0x4d:  xchgl   %ebx,in_Debugger.0
> > db> trace
> > Debugger(c05ee3e7,c063a060,160,c05ed7e2,100) at Debugger+0x4d
> > __panic(c05ed7e2,160,c05ed876,0,c05f0ef4) at __panic+0xe8
> > _mtx_lock_spin_flags(c063bb9c,0,c05f0ef4,c1,0) at _mtx_lock_spin_flags+0x7f
> > sleepq_lookup(c0638724,c0c21d08,c04aaefa,c0638700,0) at sleepq_lookup+0x67
> > sleepq_signal(c0638724,1,ffffffff,c0c21d20,c04a79bb) at sleepq_signal+0x3b
> > cv_signal(c0638724,0,c05ec985,d2,c0c21d44) at cv_signal+0x21
> > mac_policy_release_exclusive(c05eca89,c07d4539,c07d4522,0,c1507f00) at
> > mac_policy_release_exclusive+0x5b
> > mac_policy_register(c07d5a60,c26000,c0c21d7c,c04aa4b1,c1507f00) at
> > mac_policy_register+0x153
> > mac_policy_modevent(c1507f00,0,c07d5a60,c04a7b97,c0638724) at
> > mac_policy_modevent+0x4c
> > module_register_init(c07d5a80,c1ec00,c1e000,c1ec00,c1e000) at
> > module_register_init+0x91 mi_startup() at mi_startup+0x99
> > begin() at begin+0x2c
> 
> This is a bug in MAC.  cv_signal() doesn't work until the sleep
> subsystem is initialized which is done as part of proc0_init() (calls
> sleepinit()).  Probably we can call sleepinit() from a SYSINIT prior to
> SI_SUB_MAC, but there isn't a fully constructed proc0 until
> SI_SUB_INTRINSIC and thus no real threads to be waking up or going to
> sleep, so calling cv_signal() this early at all is at best nonsensical. 

Hmm.  So MAC uses a similar approach to VFS registration in that boot-time
registration and later load registration use the same sysinits.  The CV is
necessary during later loading to wait for the Framework to become
"unbusy" before modifying the policy list, but is not necessary earlier in
the boot process.  So I guess the question is, how to share the same
registration mechanism but behave differently at the different points. 
This will probably come up with other module subsystems as well in time,
as they become more synchronization-aware.  Should I just key use of
synchronization to a flag that's set later?

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert_at_fledge.watson.org      Senior Research Scientist, McAfee Research