Date: Mon, 29 Mar 2004 13:27:13 -0500 (EST) From: Robert Watson <rwatson@nailabs.com> To: FreeBSD-gnats-submit@FreeBSD.org Subject: kern/64903: multiple kldload of a module compiled into kernel can panic Message-ID: <200403291827.i2TIRDkb057263@cboss.rv.nailabs.com> Resent-Message-ID: <200403291840.i2TIe0im081429@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 64903
>Category: kern
>Synopsis: multiple kldload of a module compiled into kernel can panic
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Mon Mar 29 10:40:00 PST 2004
>Closed-Date:
>Last-Modified:
>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:
>Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403291827.i2TIRDkb057263>