zfs: using, then destroying a snapshot sometimes panics zfs

[Fabian Keil]

Stefan Bethke <stb at lassitu.de> wrote:

> Am 18.02.2009 um 07:55 schrieb Stefan Bethke:
> 
> > # cd /tank/foo/.zfs
> > # ls -l
> > ls: snapshot: Bad file descriptor
> > total 0
> > # cd snapshot
> > -su: cd: snapshot: Not a directory
> 
> > Trying to umount produces a panic:
> > # zfs umount /jail/foo
> >
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 1; apic id = 01
> > fault virtual address	= 0xa8
> > fault code		= supervisor write data, page not present
> > instruction pointer	= 0x8:0xffffffff802ee565
> > stack pointer	        = 0x10:0xfffffffea29c39e0
> > frame pointer	        = 0x10:0xfffffffea29c39f0
> > code segment		= base 0x0, limit 0xfffff, type 0x1b
> > 			= DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags	= interrupt enabled, resume, IOPL = 0
> > current process		= 51383 (zfs)
> > [thread pid 51383 tid 100298 ]
> > Stopped at      _sx_xlock+0x15: lock cmpxchgq   %rsi,0x18(%rdi)
> > db> bt
> > Tracing pid 51383 tid 100298 td 0xffffff00a598e720
> > _sx_xlock() at _sx_xlock+0x15
> > zfsctl_umount_snapshots() at zfsctl_umount_snapshots+0xa5
> > zfs_umount() at zfs_umount+0xdd
> > dounmount() at dounmount+0x2b4
> > unmount() at unmount+0x24b
> > syscall() at syscall+0x1a5
> > Xfast_syscall() at Xfast_syscall+0xab
> > --- syscall (22, FreeBSD ELF64, unmount), rip = 0x800f412fc, rsp =  
> > 0x7fffffffd1a8, rbp = 0x801202300 ---
> > db> call doadump
> 
> 
> The script I am using used to do:
> 1. create snapshot
> 2. copy data with rsync from the snapshot
> 3. destroy snapshot
> 
> Sometime after (anywhere between minutes an hours), the problem would  
> manifest itself.

Until I stopped doing it, I often got panics this way:

1) Build some port
2) Update the ports by rolling back the last snapshot
   to receive another one (zfs receive -vF)
3) Run mergemaster -a. Wait a few seconds.

Dumping core doesn't work on that system (known problem)
and as I usually did this from Xorg I couldn't get to
the debugger either.

Fabian