From rwatson@nailabs.com  Mon Mar 29 10:31:00 2004
Return-Path: <rwatson@nailabs.com>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 8A2A316A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 29 Mar 2004 10:31:00 -0800 (PST)
Received: from sentry.rv.nailabs.com (sentry.rv.nailabs.com [204.254.155.100])
	by mx1.FreeBSD.org (Postfix) with ESMTP id D930443D31
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 29 Mar 2004 10:30:59 -0800 (PST)
	(envelope-from rwatson@nailabs.com)
Received: by sentry.rv.nailabs.com; id NAA18207; Mon, 29 Mar 2004 13:34:04 -0500 (EST)
Received: from cboss.rv.nailabs.com(10.33.40.92) by sentry.gw.tislabs.com via smap (V5.5)
	id xma018201; Mon, 29 Mar 04 13:34:02 -0500
Received: from cboss.rv.nailabs.com (localhost [127.0.0.1])
	by cboss.rv.nailabs.com (8.12.10/8.12.10) with ESMTP id i2TIRD1A057264
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 29 Mar 2004 13:27:13 -0500 (EST)
	(envelope-from rwatson@cboss.rv.nailabs.com)
Received: (from rwatson@localhost)
	by cboss.rv.nailabs.com (8.12.10/8.12.10/Submit) id i2TIRDkb057263;
	Mon, 29 Mar 2004 13:27:13 -0500 (EST)
	(envelope-from rwatson)
Message-Id: <200403291827.i2TIRDkb057263@cboss.rv.nailabs.com>
Date: Mon, 29 Mar 2004 13:27:13 -0500 (EST)
From: Robert Watson <rwatson@nailabs.com>
Reply-To: Robert Watson <rwatson@nailabs.com>
To: FreeBSD-gnats-submit@freebsd.org
Subject: multiple kldload of a module compiled into kernel can panic
X-Send-Pr-Version: 3.113

>Number:         64903
>Category:       kern
>Synopsis:       [modules] panic: multiple kldload of a module compiled into kernel can panic
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    rwatson
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Mar 29 10:40:00 PST 2004
>Closed-Date:    Sat Nov 24 21:16:54 UTC 2007
>Last-Modified:  Sat Nov 24 21:16:54 UTC 2007
>Originator:     Robert Watson
>Release:        FreeBSD 5.2-CURRENT i386
>Organization:
McAfee Research
>Environment:
System: FreeBSD cboss.rv.nailabs.com 5.2-BETA FreeBSD 5.2-BETA #0: Sun Nov 30 11:32:13 EST 2003 rwatson@cboss.rv.nailabs.com:/data/obj/usr/src/sys/CBOSS i386


>Description:

Compile a piece of software (say, if_tun) into the kernel.  Then attempt
to kldload it.  kern_module.c:module_register() will fail, but this
failure isn't propagated in such a way that we don't later try to
process sysctls and sysinits for the module.

Previously, this was somewhat non-fatal: we potentially corrupted the
data structures associated with a software module by initializing them
repeatedly after the module was running (and potentially eventually
causing a disaster).  Now, we will panic immediately because the
INVARIANTS code in the mutex implementation detacts a duplication
initialization of a mutex.

>How-To-Repeat:

# kldload if_tun
module_register: module if_tun already exists!
Module if_tun failed to register: 17
can't re-use a leaf (if_tun_debug)!
panic: mutex "tunmtx" 0xc095f620 already initialized
at line 809 in file ../../../kern/kern_mutex.c
cpuid = 0; 
Debugger("panic")
Stopped at      Debugger+0x55:  xchgl   %ebx,in_Debugger.0
db> trace
Debugger(c086fa43,0,329,c086ee3e,100) at Debugger+0x55
__panic(c086ee3e,329,c086f07e,c0878c55,c095f620) at __panic+0x172
mtx_init(c095f620,c0878c55,0,0,c21cdacc) at mtx_init+0x80
tunmodevent(c1293e40,0,0,c092d920,0) at tunmodevent+0x3c
module_register_init(c21cdacc,c086dbdd,cd52bc5c,cd52bc60,0) at module_register_i
nit+0x91
linker_file_sysinit(c20a5200,c20249e0,cd52bc84,1,c20a5200) at linker_file_sysini
t+0xa0
linker_load_file(c20249e0,cd52bca8,0,c1f27400,0) at linker_load_file+0x107
linker_load_module(0,c1f27400,0,0,cd52bcd4) at linker_load_module+0xd7
kldload(c1ff57e0,cd52bd14,4,4,1) at kldload+0x123
syscall(2f,2f,2f,0,bfbfed64) at syscall+0x2a0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (304, FreeBSD ELF32, kldload), eip = 0x280bd03f, esp = 0xbfbfed0c, e
bp = 0xbfbfed38 ---

>Fix:

None attached.  However, what probably needs to happen is that the kernel
module/linker code needs to have a way to fail the load of particular
modules in a file while not failing the entire file.  I.e., to have
inactive modules that aren't hooked up to the running kernel (i.e., they
are already present more than once).  This suggests a far more complex
module interface capable of expressing the more complex notions of
files with many modules ("Are any of you unwilling to unload?"), which
in turn suggests perhaps we should limit ourselves to one module per
file, or just fail stop hard in the more complex situations.

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: kmacy 
State-Changed-When: Fri Nov 16 01:17:35 UTC 2007 
State-Changed-Why:  

This is likely no longer an issue. Need a follow up. 


Responsible-Changed-From-To: freebsd-bugs->rwatson 
Responsible-Changed-By: kmacy 
Responsible-Changed-When: Fri Nov 16 01:17:35 UTC 2007 
Responsible-Changed-Why:  

This is likely no longer an issue. Need confirmation. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=64903 
State-Changed-From-To: feedback->closed 
State-Changed-By: rwatson 
State-Changed-When: Sat Nov 24 21:16:14 UTC 2007 
State-Changed-Why:  
This indeed appears to be resolved--we now get somewhat messy but essentially 
functional error instead of a kernel panic when trying to load if_tun (and 
friends) when already compiled into the kernel.  Closing the PR. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=64903 
>Unformatted:
Can this still be reproduced? I have seen similar issues with loading a module in the loader, and 
then again later, but they don't result in panic.
