Bug #1030

msdosfs umount panic

Added by corecode over 6 years ago. Updated 7 months ago.

Status:In ProgressStart date:
Priority:NormalDue date:
Assignee:tuxillo% Done:

0%

Category:VFS subsystem
Target version:3.8.0

Description

Hey,

just happened when umounting my mp3 player. I had a "file system full"
before, in case this is important. dump way too large to upload. I'll be
away for bicycle tour the next weeks, so if you need details, sorry :) UP
system.

panic: assertion: dep == deq in msdosfs_hashrem

#0 dumpsys () at ./machine/thread.h:83
#1 0xc018a40c in boot (howto=256) at
/usr/build/src/sys/kern/kern_shutdown.c:375
#2 0xc018a561 in panic (fmt=0xe5ab76b7 "assertion: %s in %s")
at /usr/build/src/sys/kern/kern_shutdown.c:800
#3 0xe5aaf8c2 in msdosfs_hashrem (dep=0xd8695b10)
at /usr/build/src/sys/vfs/msdosfs/msdosfs_denode.c:208
#4 0xe5aaf927 in msdosfs_reclaim (ap=0xe593fa54)
at /usr/build/src/sys/vfs/msdosfs/msdosfs_denode.c:679
#5 0xc01e36ac in vop_reclaim (ops=0xd4c0ca50, vp=0xdbc786e8)
at /usr/build/src/sys/kern/vfs_vopops.c:624
#6 0xc01d8858 in vclean_vxlocked (vp=0xdbc786e8, flags=8)
at /usr/build/src/sys/kern/vfs_subr.c:1154
#7 0xc01d88d9 in vgone_vxlocked (vp=0xdbc786e8) at
/usr/build/src/sys/kern/vfs_subr.c:1296
#8 0xc01da70a in vflush_scan (mp=0xdbb95918, vp=0xdbc786e8, data=0xe593fbdc)
at /usr/build/src/sys/kern/vfs_mount.c:1151
#9 0xc01da8dc in vmntvnodescan (mp=0xdbb95918, flags=2, fastfunc=0,
slowfunc=0xc01da690 <vflush_scan>, data=0xe593fbdc) at
/usr/build/src/sys/kern/vfs_mount.c:983
#10 0xc01daa65 in vflush (mp=0xdbb95918, rootrefs=0, flags=0)
at /usr/build/src/sys/kern/vfs_mount.c:1094
#11 0xe5ab34c5 in msdosfs_unmount (mp=0xdbb95918, mntflags=0)
at /usr/build/src/sys/vfs/msdosfs/msdosfs_vfsops.c:655
#12 0xc01dfd94 in dounmount (mp=0xdbb95918, flags=0) at
/usr/build/src/sys/kern/vfs_syscalls.c:705
#13 0xc01e0051 in sys_unmount (uap=0xe593fcf0) at
/usr/build/src/sys/kern/vfs_syscalls.c:590
#14 0xc02a91ce in syscall2 (frame=0xe593fd40) at
/usr/build/src/sys/platform/pc32/i386/trap.c:1374
#15 0xc029a166 in Xint0x80_syscall () at
/usr/build/src/sys/platform/pc32/i386/exception.s:876

cheers
simon

History

#1 Updated by tuxillo about 5 years ago

Hi all,

Type: VM inside VMware
Release: 2.3.2 (Aug, 19)
Mem: 256MB

I've done the following:

> dd if=/dev/zero of=msdos.img bs=1m count=100
> sudo vnconfig vn0 msdos.img
> fdisk -i vn0
(sysid=11 which is FAT)

> sudo newfs_msdos /dev/vn0
> sudo mount /dev/vn0 /mnt/test && cd /mnt/test
>

In order to reproduce the issue, I wanted to fill up the FS to then umount it,
but instead I found:

- A lot of messages in syslog: hammer_ip_add_bulk: reservation failed
> dmesg | grep ip_add_bulk |wc -l
1676
- System almost unresponsive.
- Cannot break ^C (had to ^Z)

After supending the process, the system becomes intermittently unresponsive,
writting the hammer_ip_add_bulk message to syslog every 30 seconds more or less
(I think there's a sync by that time).

I will try to catch the kernel trace when that happens. I've been unable due
VMWare hotkeys, too bad.

#2 Updated by tuxillo 8 months ago

  • Description updated (diff)
  • Category set to VFS subsystem
  • Status changed from New to Feedback
  • Assignee deleted (0)
  • Target version set to 3.8.0

Hi,

Checked with:

# newfs_msdos /dev/vkd1
/dev/vkd1: 8372216 sectors in 1046527 FAT32 clusters (4096 bytes/cluster)
bps=512 spc=8 res=32 nft=2 mid=0xf0 spt=63 hds=255 hid=0 bsec=8388608 bspf=8177 rdcl=2 infs=1 bkbs=2

Then multiple dd's until:

# dd if=/dev/zero of=test5.img bs=1m count=512
dd: test5.img: No space left on device
# df -h .
Filesystem Size Used Avail Capacity Mounted on
/dev/vkd1 4.0G 4.0G 1.0M 100% /mnt
# umount /mnt
kthread 0x800b440600 syncer9 has exited

Couldn't reproduce it.

Cheers,
Antonio Huete

#3 Updated by tuxillo 7 months ago

  • Status changed from Feedback to In Progress
  • Assignee set to tuxillo

corecode said:

"Unless the vnode code in msdosfs was fixed, this bug is probably still there. Not sure if it is so easy to reproduce."

Grabbing.

Also available in: Atom PDF