From owner-freebsd-current@FreeBSD.ORG Tue Mar 2 11:43:37 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 0E39A16A4D6 for ; Tue, 2 Mar 2004 11:43:37 -0800 (PST) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7C2843D1F for ; Tue, 2 Mar 2004 11:43:36 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 23907 invoked from network); 2 Mar 2004 19:43:36 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 2 Mar 2004 19:43:36 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i22JhO2A082682; Tue, 2 Mar 2004 14:43:32 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Robert Watson Date: Tue, 2 Mar 2004 14:44:51 -0500 User-Agent: KMail/1.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403021444.51489.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx 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 19:43:37 -0000 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) @ > > > ../../../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 <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org