Re: panic/hang with new WITNESS and MAC_PORTACL

On Tuesday 02 March 2004 05:03 am, Michal Mertl wrote:
> From my first build after the new sleepqueues went in I'm unable to boot.
> With WITNESS compiled in I get a panic and without it the system freezes
> and only the hard reset helps.
>
> The panic/hang happens very early on boot. I have 'options MAC' in my
> kernel config and I'm loading mac_portacl as a module - I have
> 'mac_portacl_load="YES"' in /boot/loader.conf. When I comment it out the
> computer boots up normally. I've just tried on an amd64 machine and it
> panics too with MAC_PORTACL in the kernel (the platform doesn't support
> kernel modules).
>
> /boot/kernel/acpi.ko text=0x3efb0 data=0x17e4+0x116c
> Copyright (c) 1992-2004 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>         The Regents of the University of California. All rights reserved.
> FreeBSD 5.2-CURRENT #0: Sun Feb 29 19:23:36 CET 2004
>     mime_at_mime-s.dial-up.cz:/usr/src/sys/i386/compile/GOLEM-DEBUG
> Calibrating clock(s) ... i8254 clock: 1193041 Hz
> CLK_USE_I8254_CALIBRATION not specified - using default frequency
> Timecounter "i8254" frequency 1193182 Hz quality 0
> Calibrating TSC clock ... TSC clock: 699667549 Hz
> CPU: AMD Duron(tm) processor (699.67-MHz 686-class CPU)
>   Origin = "AuthenticAMD"  Id = 0x631  Stepping = 1
> avail memory = 252555264 (240 MB)
> Security policy loaded: TrustedBSD MAC/portacl (trustedbsd_mac_portacl)
> 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.

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