From owner-freebsd-current@FreeBSD.ORG Tue Mar 2 09:41:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C66216A4CE; Tue, 2 Mar 2004 09:41:53 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA86043D2F; Tue, 2 Mar 2004 09:41:52 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i22HehDL007019; Tue, 2 Mar 2004 12:40:43 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i22HehiH007016; Tue, 2 Mar 2004 12:40:43 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 2 Mar 2004 12:40:43 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: John Baldwin In-Reply-To: <200403021153.31053.jhb@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Michal Mertl cc: current@FreeBSD.org Subject: Re: panic/hang with new WITNESS and MAC_PORTACL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2004 17:41:53 -0000 On Tue, 2 Mar 2004, John Baldwin wrote: > > panic: mtx_lock_spin() of sleep mutex (null) @ > > ../../../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@fledge.watson.org Senior Research Scientist, McAfee Research