From dan@kulesh.obluda.cz  Sun Sep  5 05:34:41 2004
Return-Path: <dan@kulesh.obluda.cz>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 2269B16A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Sun,  5 Sep 2004 05:34:41 +0000 (GMT)
Received: from kulesh.obluda.cz (kulesh.obluda.cz [193.179.22.243])
	by mx1.FreeBSD.org (Postfix) with ESMTP id D5FCF43D2F
	for <FreeBSD-gnats-submit@freebsd.org>; Sun,  5 Sep 2004 05:34:39 +0000 (GMT)
	(envelope-from dan@kulesh.obluda.cz)
Received: from kulesh.obluda.cz (localhost.eunet.cz [127.0.0.1])
	by kulesh.obluda.cz (8.13.1/8.13.1) with ESMTP id i855YbPA000639
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 5 Sep 2004 07:34:37 +0200 (CEST)
	(envelope-from dan@kulesh.obluda.cz)
Received: (from root@localhost)
	by kulesh.obluda.cz (8.13.1/8.13.1/Submit) id i855Yb4e000638;
	Sun, 5 Sep 2004 07:34:37 +0200 (CEST)
	(envelope-from dan)
Message-Id: <200409050534.i855Yb4e000638@kulesh.obluda.cz>
Date: Sun, 5 Sep 2004 07:34:37 +0200 (CEST)
From: Dan Lukes <dan@obluda.cz>
Reply-To: Dan Lukes <dan@obluda.cz>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: panic due mac_policy_list_conditional_busy called before mac_init
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         71388
>Category:       kern
>Synopsis:       [panic] due mac_policy_list_conditional_busy called before mac_init
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    rwatson
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Sep 05 05:40:20 GMT 2004
>Closed-Date:    Sun Jan 27 11:10:14 UTC 2008
>Last-Modified:  Sun Jan 27 11:10:14 UTC 2008
>Originator:     Dan Lukes
>Release:        FreeBSD 5.3-BETA3 i386
>Organization:
Obludarium
>Environment:
System: FreeBSD 5.3-BETA3 #5: Sun Sep 5 05:30:03 CEST 2004 /usr/obj/usr/src/sys/Dan i386
cvsup of RELENG_5 on Sep  5 01:55 CEST
src/sys/kern/kern_mac.c,v 1.113 2004/07/15 08:26:05 phk

option MAC within kernel configuration file; 
no other MAC_* options nor modules
SMP, ACPI

a kernel loadable module with an external reference that can't be resolved
by linker

>Description:
	On the start of boot, when linker link the preloaded modules,
including the one with unresolvable external reference, the system paniced:

panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/kern_mac.c:239

>How-To-Repeat:
	Preload module that has unresolvable reference
(for example, if_fxp when miibus.ko unavaiable) on boot (kernel with MAC
compiled-in)

>Fix:

	I'm sorry, no exact fix hint. 

	The relevant part of source:
src/sys/kern/kern_mac.c:
233: int
234: mac_policy_list_conditional_busy(void)
235: {
236: #ifndef MAC_STATIC
237:         int ret;
238: 
239:         mtx_lock(&mac_policy_mtx);

	The mac_policy_mtx is NULL as mac_init has not been called yet.

	The mac_policy_list_conditional_busy is called from
mac_check_kld_unload via MAC_CHECK macro.

	Althought I have no back-trace, the caller of mac_check_kld_unload
seems to be link_elf_link_preload via linker_file_unload.

	I'm not sure about the best place to test that the MAC layer is not
initialized yet. May be mac_policy_list_conditional_busy should return error
when called with mac_policy_mtx==NULL 
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->rwatson 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Sat Sep 11 22:25:36 GMT 2004 
Responsible-Changed-Why:  
Over to the mac guru. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=71388 
State-Changed-From-To: open->patched 
State-Changed-By: rwatson 
State-Changed-When: Mon Jan 3 11:57:18 GMT 2005 
State-Changed-Why:  
This change is believed to have been fixed in FreeBSD CVS HEAD 
kern_mac.c:1.114 and in RELENG_5 kern_mac.c:1.113.4.1 prior to the FreeBSD 
5.3 release.  Could you confirm that this problem has gone away for you 
with later revisions? 

---------------------------- 
revision 1.114 
date: 2004/10/30 14:20:59;  author: rwatson;  state: Exp;  lines: +21 -0 
Disable use of synchronization early in the boot by the MAC Framework; 
for modules linked into the kernel or loaded very early, panics will 
result otherwise, as the CV code it calls will panic due to its use 
of a mutex before it is initialized. 
---------------------------- 



http://www.freebsd.org/cgi/query-pr.cgi?pr=71388 

From: Dan Lukes <dan@obluda.cz>
To: Robert Watson <rwatson@FreeBSD.org>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/71388: [panic] due mac_policy_list_conditional_busy called
 before mac_init
Date: Wed, 05 Jan 2005 01:07:10 +0100

 Robert Watson napsal/wrote, On 01/03/05 13:00:
 > RELENG_5 kern_mac.c:1.113.4.1 prior to the FreeBSD 5.3 release
 
 	Note, it's 1.113.2.1 in RELENG_5
 
 
 	I'm sorry, I can't confirm the success. The todays RELENG_5 kernel 
 reboots early during boot (without a message) when "bad" module is 
 preloaded. But it isn't related to MAC as kernel reboots without MAC 
 compiled in also ...
 					Dan
 
State-Changed-From-To: patched->feedback 
State-Changed-By: rwatson 
State-Changed-When: Sun Nov 27 18:38:09 GMT 2005 
State-Changed-Why:  
Walking my open PRs and noticed this is still open.  Did you ever manage 
to track down the source of this problem?  If so (or if you were able to 
confirm it was not a MAC problem), I'd like to close the bug report. 

Thanks! 


http://www.freebsd.org/cgi/query-pr.cgi?pr=71388 

From: Dan Lukes <dan@obluda.cz>
To: bug-followup@FreeBSD.org
Cc: Robert Watson <rwatson@FreeBSD.org>
Subject: Re: kern/71388: [panic] due mac_policy_list_conditional_busy called
 before mac_init
Date: Wed, 30 Nov 2005 19:49:39 +0100

 Robert Watson napsal/wrote, On 11/27/05 19:40:
 > Did you ever manage to track down the source of this problem?  
 
 	Unfortunatelly not. I can confirm the problem is still present  on 
 current RELENG-6 kernel.
 
 	Actual situation:
 -------------------
 pure GENERIC boot with bad.ko (and automatically preloaded acpi.ko):
 
 FreeBSD 6.0-STABLE #0: Wed Nov 30 18:22:49 CET 2005 Nov 30 18:35:43 
 kulesh kernel: dan@kulesh.obluda.cz:/usr/obj/usr/src/sys/GENERIC
 
 module bad already present!
 link_elf: symbol _mtx_assert undefined
 KLD file acpi.ko - could not finalize loading
 MPTable: <INTEL    I865G/GE/PE >
 Timecounter "i8254" frequency 1193182 Hz quality 0
 ...
 
 	System booted normally (but without acpi)
 -------------------
 	With my custom kernel it reboot early during boot. I catched the messages:
 
 kernel boot file is /boot/kernel/kernel
 bind non-running thread
 cpuid = 0
 panic: sched_bind: cannot bind non-running thread
 cpuid = 0
 ... [those messages repeaded next 62 times]
 Fatal double fault:
 eip = 0xc05d163b
 esp = 0xc081e000
 ebp = 0xc081e018
 cpuid = 0; apic id = 00
 panic: double fault
 cpuid = 0
 panic: double fault
 cpuid = 0
 panic: double fault
 cpuid = 0
 panic: double fault
 cpuid = 0
 [ automatic reboot with no question ]
 ----------------
 
 	But it isn't related to MAC as kernel reboots with or without MAC 
 compiled in ...
 
 > If so (or if you were able to
 > confirm it was not a MAC problem), I'd like to close the bug report.
 
 	For now, I can't build an kernel with MAC which can boot with bad 
 loadable module. Current problems seems not to be related to MAC, 
 unfortunatelly, due those problems I can't test if MAC related problem 
 has been succesfully resolved by your patch.
 
 					Dan
 
 
 -- 
 Dan Lukes                                   SISAL MFF UK
 AKA: dan@obluda.cz, dan@freebsd.cz,dan@kolej.mff.cuni.cz
State-Changed-From-To: feedback->closed 
State-Changed-By: rwatson 
State-Changed-When: Sun Jan 27 11:08:19 UTC 2008 
State-Changed-Why:  
Close, as it sounds like the MAC problem is resolved.  Please open a new 
report for the other problem you're experiencing if it persists. 

BTW, that printg about mtx_assert suggests that you are loading at least 
one module compiled with an invariants kernel, but that the kernel you're 
using is not compiled with invariant_support.  It could be that the ABI 
between the modules and the kernel doesn't match, which might well result 
in a panic, as invariant_support changes the size of kernel data 
structures.  You might want to confirm all modules and the kernel have 
moderately matching configurations with respect to ABI. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=71388 
>Unformatted:
