kern/50664: "cd .." over NFS/ZFS can panic kernel

[marcotte%panix.com@localhost]

>Number:         50664
>Category:       kern
>Synopsis:       "cd .." over NFS/ZFS can panic kernel
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jan 17 04:45:01 +0000 2016
>Originator:     Brian Marcotte
>Release:        6.1.5
>Organization:
Public Access Networks, Corp.
>Environment:
NetBSD panix1.panix.com 6.1.5 NetBSD 6.1.5 (PANIX-XEN-USER) #0: Tue Oct 27 18:53:48 EDT 2015  root%juggler.panix.com@localhost:/misc/obj/misc/devel/netbsd/6.1.5/src/sys/arch/i386/compile/PANIX-XEN-USER i386
>Description:
Where "/net/u" is a ZFS filesystem NFS mounted from another server:

  cd /net/u/.zfs/shares
  cd ..

causes this panic in 6.1.5:

Reader / writer lock error: rw_vector_enter: locking against myself

lock address : 0x00000000cd3284d4
current cpu  :                  0
current lwp  : 0x00000000c390eaa0
owner/count  : 0x00000000c390eaa0 flags    : 0x0000000000000004

panic: lock error
cpu0: Begin traceback...
panic(c0393911,c038a362,c036fe68,c03893c3,cd3284d4,0,c390eaa0,cd3284d4,c390eaa4,db34d944) at netbsd:panic+0x18
lockdebug_abort(cd3284d4,c03a6864,c036fe68,c03893c3,db34d984,c01e52b3,8200,db34d9bc,c0233fb8,cd328430) at netbsd:lockdebug_abort+0x2f
rw_abort.clone.1(8200,db34d9bc,c0233fb8,cd328430,db34da44,1,3,1,c390eaa4,c390eaa0) at netbsd:rw_abort.clone.1+0x32
rw_vector_enter(cd3284d4,1,1,cd328430,20000,db34d9c4,c032eeea,db34d9b4,0,0) at netbsd:rw_vector_enter+0x1a3
genfs_lock(db34d9b4,0,0,c037a134,cd328430,2,cd328430,db34d9e4,c0325c76,cd328430) at netbsd:genfs_lock+0xae
VOP_LOCK(cd328430,2,2,0,8200,db34da44,db34daf8,c0235677,cd328430,20002) at netbsd:VOP_LOCK+0x4a
vn_lock(cd328430,20002,ca859900,db34da08,c0338cf2,6,c05b7000,db34da48,c011dc1d,cad9ed88) at netbsd:vn_lock+0x76
nfs_lookup(db34db0c,c01d29d4,0,c0379d08,cd328430,db34db58,db34dc7c,cd328430,db34db68,c03172b8) at netbsd:nfs_lookup+0x1207
VOP_LOOKUP(cd328430,db34db58,db34dc7c,0,c037a134,cd328430,ca51d738,db34dc58,db34dc2c,c390eaa0) at netbsd:VOP_LOOKUP+0x50
lookup_once(db34dbfc,db34dbf8,4,21,c3108dc0,cd328430,db34dc1c,db34dcac,c02ff183,ca8336e0) at netbsd:lookup_once+0x178
namei_tryemulroot(0,db34dc58,db34dc7c,20,0,1,ca51d738,db34dca4,c031fa5a,db34dc58) at netbsd:namei_tryemulroot+0x1c6
namei(db34dc58,db34dc98,db34dc98,c6486280,cb38bc00,c3108dc0,0,1,0,1) at netbsd:namei+0x41
chdir_lookup(80dd308,0,db34dcc0,c390eaa0,1a27750b,c390eaa0,c390eaa0,db34dd48,db34dd3c,c02b3f4a) at netbsd:chdir_lookup+0x5a
sys_chdir(c390eaa0,db34dd00,db34dd28,c,8121000,0,db34dd00,ca51d738,2,bb729e87) at netbsd:sys_chdir+0x35
syscall(db34dd48,bb7e00b3,ab,1f,bf7f001f,bb7ea000,0,bf7fe6b4,0,80dd30a) at netbsd:syscall+0xaa
cpu0: End traceback...

NetBSD 7.0 doesn't panic, but the process will wait in "tstile" forever.

>How-To-Repeat:
NFS mount a ZFS filesystem and run the above commands. In our case, the
NFS server is OmniOS, an OpenSolaris derivative.

We can probably provide a couple of virtual hosts for debugging this if
desired.

>Fix:
Unknown