Created attachment 224098 [details] script to reproduce the bug Here is a small shell script to reproduce a race bug with mount/umount. A beginning of explanation by Chuck Silvers: "the umount command prefers to tell the kernel which fs to unmount not by the path that it is given on the command line, but rather by fsid, which it gets from the getfsstat() syscall. There is code in the kernel mount syscall that is supposed to detect this and generate an unique, ephemeral fsid if an ffs file system being mounted has the same fsid on disk as another file system that is already mounted, but that code has a race that can cause it to miss detecting the duplicate fsid if the two mounts of file systems with the same on-disk fsid happen at the same time." Once started this shell script should display this kind of output: # ./bug.sh Initializing... Creating one 500MB file... Creating md device to newfs it (mkimage ??)... newfs it... /dev/md0: 500.0MB (1024000 sectors) block size 32768, fragment size 4096 using 4 cylinder groups of 125.03MB, 4001 blks, 16128 inodes. super-block backups (for fsck_ffs -b #) at: 192, 256256, 512320, 768384 Destroying md device md0... Ready to trigger bug! [2] Copying /tmp/mount_bug into /tmp/2... [1] Copying /tmp/mount_bug into /tmp/1... [1] Creating md device... [1] mount md0 into /tmp/1.mnt... [2] Creating md device... [2] mount md1 into /tmp/2.mnt... [1] fsid of the mount point /tmp/1.mnt/: superblock location 65536 id [ 6076b0bb 46c244a6 ] [1] Creating a file into it /tmp/1.mnt/... [2] fsid of the mount point /tmp/2.mnt/: superblock location 65536 id [ 6076b0bb 46c244a6 ] [2] Creating a file into it /tmp/2.mnt/... [1] unmount /tmp/1.mnt... umount: unmount of /tmp/1.mnt failed: Device busy [2] unmount /tmp/2.mnt... umount failed because: 1) it umounted the wrong (still creating file) or 2) already unmount by the other! [1] Destroying md device md0... mdconfig: ioctl(/dev/mdctl): Device busy destroying md device failed, because still mounted [1] cleaning up... [2] Destroying md device md1... [2] cleaning up... rm: /tmp/1.mnt: Device busy
Created attachment 237865 [details] script to reproduce the bug
Source of the problem in vfs_getnewfsid() in sys/kern/vfs_subr.c that has this comment: * Keep in mind that several mounts may be running in parallel. Starting * the search one past where the previous search terminated is both a * micro-optimization and a defense against returning the same fsid to * different mounts. This protection doesn't work here.