kern/102250: panic upon forced umount of removed medium
Thomas Quinot
thomas at cuivre.fr.eu.org
Fri Aug 18 22:20:17 UTC 2006
>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 at 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:
>Unformatted:
More information about the freebsd-bugs
mailing list