Bug #1014

panic when umounting a msdosfs mount: "VOP_STDCLOSE: BAD WRITECOUNT 0xf2629e68 0"

Added by rumcic over 6 years ago. Updated about 6 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

After playing with my mobile phone (mounted it's memory card with mount -t
msdosfs), a umount triggered the panic (well, I did run sync a second or 2
before doing a umount). The memory dump is at leaf:~rumko/crash/19.05.2008/
and the backtrace (including the kernel message buffer that kgdb prints) is
here:

Unread portion of the kernel message buffer:
panic: VOP_STDCLOSE: BAD WRITECOUNT 0xf2629e68 0

mp_lock = 00000001; cpuid = 1
boot() called on cpu#1

syncing disks... 3 ad8: WARNING - SETFEATURES SET TRANSFER MODE taskqueue
timeout - completing request directly
ad8: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=12361855

done
Uptime: 21h9m5s

dumping to dev #ad/0x20041, blockno 4204800
dump 2046 2045 ... 1 0

GNU gdb 6.7.1
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-dragonfly".
(kgdb) bt
#0 dumpsys () at ./machine/thread.h:83
#1 0xc02733c5 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:375
#2 0xc0273688 in panic (fmt=0xc0521f34 "VOP_STDCLOSE: BAD WRITECOUNT %p %d\n")
at /usr/src/sys/kern/kern_shutdown.c:800
#3 0xc02b55f5 in vop_stdclose (ap=0xf49f0bf8)
at /usr/src/sys/kern/vfs_default.c:1191
#4 0xc02caf0f in spec_close (ap=0xf49f0bf8)
at /usr/src/sys/vfs/specfs/spec_vnops.c:763
#5 0xc03c3e6e in ufsspec_close (ap=0xf49f0bf8)
at /usr/src/sys/vfs/ufs/ufs_vnops.c:1947
#6 0xc03c1f44 in ufs_vnoperatespec (ap=0xf49f0bf8)
at /usr/src/sys/vfs/ufs/ufs_vnops.c:2462
#7 0xc02c5f8e in vop_close (ops=0xd3a0c150, vp=0xf2629e68, fflag=3)
at /usr/src/sys/kern/vfs_vopops.c:257
#8 0xc02cf827 in msdosfs_unmount (mp=0xda422060, mntflags=0)
at /usr/src/sys/vfs/msdosfs/msdosfs_vfsops.c:672
#9 0xc02c2f7a in dounmount (mp=0xda422060, flags=0)
at /usr/src/sys/kern/vfs_syscalls.c:705
#10 0xc02c31c7 in sys_unmount (uap=0xf49f0cf0)
at /usr/src/sys/kern/vfs_syscalls.c:590
#11 0xc049a37d in syscall2 (frame=0xf49f0d40)
at /usr/src/sys/platform/pc32/i386/trap.c:1349
#12 0xc0487be6 in Xint0x80_syscall ()
at /usr/src/sys/platform/pc32/i386/exception.s:876
#13 0x0804ace8 in ?? ()
--
Regards,
Rumko

History

#1 Updated by dillon over 6 years ago

:After playing with my mobile phone (mounted it's memory card with mount -t
:msdosfs), a umount triggered the panic (well, I did run sync a second or 2
:before doing a umount). The memory dump is at leaf:~rumko/crash/19.05.2008/
:and the backtrace (including the kernel message buffer that kgdb prints) is
:here:
:
:Unread portion of the kernel message buffer:
:panic: VOP_STDCLOSE: BAD WRITECOUNT 0xf2629e68 0
:
:mp_lock = 00000001; cpuid = 1
:boot() called on cpu#1
:
:syncing disks... 3 ad8: WARNING - SETFEATURES SET TRANSFER MODE taskqueue
:timeout - completing request directly
:ad8: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=12361855
:
:done
:--
:Regards,
:Rumko

Did you mount it normally or use options like -o ro (read-only), or
-u (update) at any point ?

And, is the panic reproducable?

-Matt
Matthew Dillon
<>

#2 Updated by rumcic over 6 years ago

Matthew Dillon wrote:

If I remember correctly, I did mount it readonly, then did a umount -u, copied
a file, ran sync (I'm not sure, but could've been more than one time) and
tried umount-ing it.

As for being reproducable ... I can try it again, if the need to reproduce it
arises.
--
Regards,
Rumko

#3 Updated by dillon over 6 years ago

:If I remember correctly, I did mount it readonly, then did a umount -u, copied
:a file, ran sync (I'm not sure, but could've been more than one time) and
:tried umount-ing it.
:
:As for being reproducable ... I can try it again, if the need to reproduce it
:arises.
:--
:Regards,
:Rumko

Being able to reproduce it allows you to test to see if my patch fixes
the problem!

However, in this case you don't need to worry about it. I can reproduce
the bug from the information you have given me and I will commit a fix
to HEAD very soon.

-Matt
Matthew Dillon
<>

#4 Updated by rumcic over 6 years ago

Matthew Dillon wrote:

Well, my plan was to reserve a couple of hours after you'd send a patch and
first update to -HEAD again and try to reproduce it and apply the patch and
try again ...
--
Regards,
Rumko

#5 Updated by rumcic over 6 years ago

Rumko wrote:

Well after that commit to HEAD, I can't reproduce the panic anymore (did play
quite a lot with that mount, but it worked without problems).
--
Regards,
Rumko

#6 Updated by matthias about 6 years ago

Committed fix works according to rumcic, so close the issue

Also available in: Atom PDF