snapshot_mount: already on list

[Emmanuel Dreyfus <manu%netbsd.org@localhost>]

Hello

Some times ago, I encountered this nasty bug where the kernel
would crash when mounting a filesystem with snapshots. I thought
it was fixed, but it seems there are some problems leftover, at least
on netbsd-8. 

The crash:

/mail: replaying log to disk
ffs_snapshot_mount: vget failed 2
panic: ffs_snapshot_mount: 211471882 already on list
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip 0xffffffff8021fe95 cs 0x8 rflags 0x246 cr2 0x72ef770d7700 ilevel 0 rsp 0xffff80090868eb40
curlwp 0xfffffe90f4689100 pid 76.1 lowest kstack 0xffff80090868c2c0
Stopped in pid 76.1 (mount_ffs) at      netbsd:breakpoint+0x5:  leave
vpanic() at netbsd:vpanic+0x15d
snprintf() at netbsd:snprintf
ffs_snapshot_mount() at netbsd:ffs_snapshot_mount+0x371
ffs_mountfs() at netbsd:ffs_mountfs+0xafc
ffs_mount() at netbsd:ffs_mount+0x579
VFS_MOUNT() at netbsd:VFS_MOUNT+0x4d
mount_domount() at netbsd:mount_domount+0x122
do_sys_mount() at netbsd:do_sys_mount+0x2b0
sys___mount50() at netbsd:sys___mount50+0x33
syscall() at netbsd:syscall+0x1ec
--- syscall (number 410) ---

Then I booted of my kernel with snapshots disabled to cleanup inode 211471882.
The rm caused a crash:

panic: ffs_blkfree_common: freeing free block: dev = 0xa807, block = 115955440, fs = /mail
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip 0xffffffff8021fe95 cs 0x8 rflags 0x246 cr2 0 ilevel 0 rsp 0xffff800908672810
curlwp 0xfffffe910b018080 pid 10.1 lowest kstack 0xffff8009086702c0
Stopped in pid 10.1 (rm) at     netbsd:breakpoint+0x5:  leave
breakpoint(0,fffffea05fb0d000,ffff8009418d9788,ffff8009418d8000,ffff8009086728a0
,ffffffff8096f568) at netbsd:breakpoint+0x5
vpanic(0,fffffe9100000028,ffff8009086728b0,ffff800908672870,177e06d40,ffffffff81
03f370) at netbsd:vpanic+0x15d
snprintf(a807,ffffffff809a6b7a,6e956f0,fffffe90f7c1f690,8c50,6e956f0) at netbsd:
snprintf
ffs_blkfree_common(0,6e956f0,8000,fffffe90f7c1f600,a807,3808bf3b7) at netbsd:ffs
_blkfree_common+0x3d7
ffs_blkfree_cg(0,fffffe90faba2800,0,ffffffffffffffff,0,40) at netbsd:ffs_blkfree
_cg+0x131
ffs_indirtrunc(0,fffffe90faba2800,0,ffffffffffffffff,0,40) at netbsd:ffs_indirtr
unc+0x47f
ffs_indirtrunc(0,fffffe90faba2800,1,ffffffffffffffff,0,40) at netbsd:ffs_indirtr
unc+0x1fb
ffs_indirtrunc(2,2,40,0,c,10) at netbsd:ffs_indirtrunc+0x1fb
ffs_truncate(0,235fb117e8,ffff800908672d60,fffffea05fac9b00,fffffea05fb11548,fff
ffea05fb1156c) at netbsd:ffs_truncate+0xbac
ufs_truncate_retry(10,fffffea05fb11548,ffff800908672de0,fffffea05fb11548,1,fffff
ea05fb1156c) at netbsd:ufs_truncate_retry+0x92
ufs_inactive(20012,fffffea05fb11548,ffff800908672eb0,ffffffff81058e40,fffffea05f
b11548,ffff800908672e1f) at netbsd:ufs_inactive+0x25a
VOP_INACTIVE(fffffea05fb11548,ffffff809bbd91,fffffea05fb11548,fffffea05fb117e8,ffff800908672eb0,0) at netbsd:VOP_INACTIVE+0x4c
vrelel(fffffea05fac9d00,fffffea05fac9b00,ffff800908672ec0,fffffea05fb117e8,0,fff
ffe9100054000) at netbsd:vrelel+0x168
ufs_remove(0,fffffe9100054000,ffffffff810590a0,fffffea05fb117e8,fffffea05fb11548
,ffff800908672f48) at netbsd:ufs_remove+0xab
VOP_REMOVE(fffffea05f8ed008,0,fffffea05f8ed008,fffffe9100054400,fffffe90f90bad28
,0) at netbsd:VOP_REMOVE+0x50
do_sys_unlinkat.isra.5(ffffffff81400600,ffff800908672fb0,0,0,ffffffff80922368,7f
7ffffa3373) at netbsd:do_sys_unlinkat.isra.5+0x1eb
syscall() at netbsd:syscall+0x1ec
--- syscall (number 10) ---
7966dd4fb1fa:

After another reboot, I ran fsck on the fileystem, inode 211471882
indeed as troubles:

** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=211471881 (31466368 should be 31466624)
CORRECT? yes

845563840 DUP I=211471882
845563841 DUP I=211471882
845563842 DUP I=211471882
845563843 DUP I=211471882
845563844 DUP I=211471882
845563845 DUP I=211471882
845563846 DUP I=211471882
845563847 DUP I=211471882
INCORRECT BLOCK COUNT I=211471882 (11141696 should be 11142208)
CORRECT? yes



-- 
Emmanuel Dreyfus
manu%netbsd.org@localhost