From thomas@cuivre.fr.eu.org  Fri Aug 18 22:11:43 2006
Return-Path: <thomas@cuivre.fr.eu.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 188C316A4DA
	for <FreeBSD-gnats-submit@freebsd.org>; 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 <FreeBSD-gnats-submit@freebsd.org>; 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 <thomas@cuivre.fr.eu.org>
Reply-To: Thomas Quinot <thomas@cuivre.fr.eu.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: panic upon forced umount of removed medium
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         102250
>Category:       kern
>Synopsis:       [msdosfs] panic upon forced umount of removed medium
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    trasz
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Aug 18 22:20:16 GMT 2006
>Closed-Date:    Sun Jul 19 14:14:28 UTC 2009
>Last-Modified:  Sun Jul 19 14:14:28 UTC 2009
>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 <deget+12> and ends at 0xc0606725 <deget+17>.
(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:
Responsible-Changed-From-To: freebsd-bugs->trhodes 
Responsible-Changed-By: remko 
Responsible-Changed-When: Fri Dec 29 20:44:12 UTC 2006 
Responsible-Changed-Why:  
assign to tom 

http://www.freebsd.org/cgi/query-pr.cgi?pr=102250 
Responsible-Changed-From-To: trhodes->trasz 
Responsible-Changed-By: trasz 
Responsible-Changed-When: Wed Jul 8 12:36:38 UTC 2009 
Responsible-Changed-Why:  
I'll take it. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=102250 
State-Changed-From-To: open->feedback 
State-Changed-By: trasz 
State-Changed-When: Wed Jul 8 12:36:45 UTC 2009 
State-Changed-Why:  
Can you still reproduce it with FreeBSD 8.2?  It should be fixed already. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=102250 
State-Changed-From-To: feedback->closed 
State-Changed-By: trasz 
State-Changed-When: Sun Jul 19 14:14:27 UTC 2009 
State-Changed-Why:  
Seems to be fixed. 

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