Re: panic/hang with new WITNESS and MAC_PORTACL

On Tuesday 02 March 2004 12:40 pm, Robert Watson wrote:
> 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?

Well, actually, it's probably ok to just stick sleepinit() in its own SYSINIT 
prior to SI_SUB_MAC.  I would just add a SI_SUB_SLEEPQ at 0x1B80000
just after SI_SUB_LOCK and do sleepinit() there, it should be fine to do so.  
Then your cv_signal() will just be a dummy that won't do anything.

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org