From owner-freebsd-bugs@FreeBSD.ORG Fri Aug 18 22:20:17 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org 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 7AA5A16A4DF for ; Fri, 18 Aug 2006 22:20:17 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C5AA43D49 for ; Fri, 18 Aug 2006 22:20:16 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k7IMKGHE013298 for ; Fri, 18 Aug 2006 22:20:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k7IMKGvl013297; Fri, 18 Aug 2006 22:20:16 GMT (envelope-from gnats) Resent-Date: Fri, 18 Aug 2006 22:20:16 GMT Resent-Message-Id: <200608182220.k7IMKGvl013297@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, Thomas Quinot Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 188C316A4DA for ; Fri, 18 Aug 2006 22:11:43 +0000 (UTC) (envelope-from thomas@cuivre.fr.eu.org) Received: from melamine.cuivre.fr.eu.org (melusine.cuivre.fr.eu.org [82.225.155.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94BFE43D49 for ; Fri, 18 Aug 2006 22:11:40 +0000 (GMT) (envelope-from thomas@cuivre.fr.eu.org) Received: by melamine.cuivre.fr.eu.org (Postfix, from userid 1000) id BD3DD5C55D; Sat, 19 Aug 2006 00:11:38 +0200 (CEST) Message-Id: <20060818221138.BD3DD5C55D@melamine.cuivre.fr.eu.org> Date: Sat, 19 Aug 2006 00:11:38 +0200 (CEST) From: Thomas Quinot To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: kern/102250: panic upon forced umount of removed medium X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Thomas Quinot List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2006 22:20:17 -0000 >Number: 102250 >Category: kern >Synopsis: panic upon forced umount of removed medium >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Aug 18 22:20:16 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Thomas Quinot >Release: FreeBSD 6.1-RC i386 >Organization: >Environment: System: FreeBSD melamine.cuivre.fr.eu.org 6.1-RC FreeBSD 6.1-RC #0: Thu May 4 13:21:21 CEST 2006 thomas@melamine.cuivre.fr.eu.org:/space/build/obj/space/build/src/RELENG_6/sys/MELAMINE i386 >Description: A SD card is mounted through a USB flash card reader. FS type is msdos, mount is r/w. SDcard medium is then removed (the USB reader is still attached to the system). Upon umount -f, system panics. Unread portion of the kernel message buffer: (da2:umass-sim0:0:0:2): READ(10). CDB: 28 40 0 0 0 28 0 0 8 0 (da2:umass-sim0:0:0:2): CAM Status: SCSI Status Error (da2:umass-sim0:0:0:2): SCSI Status: Check Condition (da2:umass-sim0:0:0:2): ILLEGAL REQUEST asc:21,0 (da2:umass-sim0:0:0:2): Logical block address out of range (da2:umass-sim0:0:0:2): Unretryable error g_vfs_done():da2s1[READ(offset=512, length=4096)]error = 22 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0606723 stack pointer = 0x28:0xe77e2c28 frame pointer = 0x28:0xe77e2c5c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 57126 (umount) trap number = 12 panic: page fault cpuid = 0 [...] (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc064f6e1 in boot (howto=260) at /space/build/src/RELENG_6/sys/kern/kern_shutdown.c:402 #2 0xc064fa09 in panic (fmt=0xc0876a5f "%s") at /space/build/src/RELENG_6/sys/kern/kern_shutdown.c:558 #3 0xc082b75c in trap_fatal (frame=0xe77e2be8, eva=0) at /space/build/src/RELENG_6/sys/i386/i386/trap.c:836 #4 0xc082b49b in trap_pfault (frame=0xe77e2be8, usermode=0, eva=0) at /space/build/src/RELENG_6/sys/i386/i386/trap.c:744 #5 0xc082b0d5 in trap (frame= {tf_fs = 8, tf_es = -1056571352, tf_ds = -983891928, tf_edi = 0, tf_esi = -920363568, tf_ebp = -411161508, tf_isp = -411161580, tf_ebx = 22, tf_edx = -993974272, tf_ecx = -1064321120, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1067423965, tf_cs = 32, tf_eflags = 66198, tf_esp = 256, tf_ss = -973118720}) at /space/build/src/RELENG_6/sys/i386/i386/trap.c:434 #6 0xc08181aa in calltrap () at /space/build/src/RELENG_6/sys/i386/i386/exception.s:139 #7 0xc0606723 in deget (pmp=0x0, dirclust=0, diroffset=536870911, depp=0xe77e2c74) at /space/build/src/RELENG_6/sys/fs/msdosfs/msdosfs_denode.c:104 #8 0xc060afbf in msdosfs_root (mp=0x0, flags=2, vpp=0x0, td=0xc6589e10) at /space/build/src/RELENG_6/sys/fs/msdosfs/msdosfs_vfsops.c:817 #9 0xc06a4505 in dounmount (mp=0xc4c12800, flags=134742016, td=0xc6589e10) at /space/build/src/RELENG_6/sys/kern/vfs_mount.c:1117 (kgdb) info line *0xc0606723 Line 104 of "/space/build/src/RELENG_6/sys/fs/msdosfs/msdosfs_denode.c" starts at address 0xc0606720 and ends at 0xc0606725 . (kgdb) list deget 96 deget(pmp, dirclust, diroffset, depp) 97 struct msdosfsmount *pmp; /* so we know the maj/min number */ 98 u_long dirclust; /* cluster this dir entry came from */ 99 u_long diroffset; /* index of entry within the cluster */ 100 struct denode **depp; /* returns the addr of the gotten denode */ 101 { 102 int error; 103 uint64_t inode; 104 struct mount *mntp = pmp->pm_mountp; 105 struct direntry *direntptr; So it clearly looks like we obtain a null pointer in msdosfs_root when initializing struct msdosfsmount *pmp = VFSTOMSDOSFS(mp); >How-To-Repeat: >Fix: A symptomatic fix would be to add a guard for the pmp == NULL case in msdosfs_root and/or in deget, but it's still unclear to me what sequence of events can lead to that condition in the first place. >Release-Note: >Audit-Trail: >Unformatted: