-current lock up at dump -L with snapshot

[Jun Kuriyama]

I'm still tracking down why my box is usually locking up.

Reference: http://docs.freebsd.org/cgi/mid.cgi?7mznedas57.wl

I try to simplify how to reproduce this.

(a) A filesystem without any snapshot, I can take a dump -L.

(b) A filesystem with a snapshot, I can take a dump (without -L).

(c) A filesystem with a snapshot, I cannot take a dump -L.

% dump -1 -f /dev/null -S -L /       
  DUMP: Date of this level 1 dump: Thu Feb 12 23:52:43 2004
  DUMP: Date of last level 0 dump: Wed Feb 11 16:30:22 2004
  DUMP: Dumping snapshot of /dev/ad4s1a (/) to /dev/null
  DUMP: mapping (Pass I) [regular files]	<--- stopped here

This filesystem is /, so softdep is disabled, but situation is the
same with softdep.

"dump -L" is doing following:

 1) take a snapshot: "mksnap_ffs / /.snap/dump_snapshot".
 2) open a snapshot: open("/.snap/dump_snapshot", O_RDONLY).
 3) unlink a snapshot: unlink("/.snap/dump_snapshot")
 4) ...
 5) pread(2) opened snapshot.

dump(8) is locked at 5) syscall.  At that time, ddb's "show
lockedvnods" shows (line number may be different by my debug codes):

-----
0xc8194de0: tag ufs, type VREG, usecount 1, writecount 0, refcount 9, flags (VV_SYSTEM|VV_OBJBUF), lock type snplk2: SHARED (count 1) with 3 pending @ kern/vfs_vnops.c:529 by vop_stdlock (thread 0xc809a000 (pid 52934))
	ino 187, on dev ad0s1a (4, 12)
0xc777b818: tag ufs, type VREG, usecount 1, writecount 0, refcount 9, flags (VV_SYSTEM), lock type snplk2: SHARED (count 1) with 3 pending @ kern/vfs_vnops.c:529 by vop_stdlock (thread 0xc809a000 (pid 52934))
	ino 178, on dev ad0s1a (4, 12)
-----

It looks there is a problem around removing a snapshot with opened
file descriptor.  But I'm not sure why there is no problem when I have
no another snapshot in that filesystem.


Is there any hints to track this down more?  Any comments appreciated.


-- 
Jun Kuriyama <kuriyama at imgsrc.co.jp> // IMG SRC, Inc.
             <kuriyama at FreeBSD.org> // FreeBSD Project