From owner-freebsd-bugs@FreeBSD.ORG Mon Mar 29 10:40:01 2004 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B3AC16A4CE for ; Mon, 29 Mar 2004 10:40:01 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FC4D43D2D for ; Mon, 29 Mar 2004 10:40:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) i2TIe0bv081430 for ; Mon, 29 Mar 2004 10:40:00 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i2TIe0im081429; Mon, 29 Mar 2004 10:40:00 -0800 (PST) (envelope-from gnats) Resent-Date: Mon, 29 Mar 2004 10:40:00 -0800 (PST) Resent-Message-Id: <200403291840.i2TIe0im081429@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Robert Watson Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A2A316A4CE for ; 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 ; 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]) i2TIRD1A057264 for ; 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 To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: kern/64903: multiple kldload of a module compiled into kernel can panic X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Robert Watson List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2004 18:40:01 -0000 >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: