The following reply was made to PR kern/13666; it has been noted by GNATS.

From: "Julio M. Merino Vidal" <jmmv84@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/13666
Date: Fri, 3 Nov 2006 17:10:47 +0100

 I've just found more problems with respect to using special files over
 a NFS loopback mount.  Consider the following test case:
 
 # mount localhost:/foo /mnt/remote
 # cd /mnt/remote
 # mkfifo zero c 2 12
 # dd if=zero of=test bs=1k count=1
 < file system stalled >
 
 The above 'dd' command gets locked in the close(2) call; I've
 diagnosed this by writing a very simple test case that opens a device,
 reads from it and then closes it.  Note that the lockup does not
 happen if there is no read in between the open and close (more below).
 
 The problem is that nfsspec_close is calling VOP_SETATTR(vp, ...) on
 the underlying file system with vp *locked*.  Then, when the remote
 file system (running on the same machine!) tries to allocate a new
 vnode for the special file, it calls checkalias, and that routine
 locks up when scanning the special files vnodes list because one of
 them is locked.  The lockup happens in vfs_subr.c:1113 v1.275.
 
 I've tried commenting out the VOP_SETATTR call and that fixes this
 specific problem.  (This is why the lock up does not happen when not
 reading from the device before close, because the access time does not
 need to be updated.)  But then the server locks up again when removing
 the special file.
 
 Similar problems arise when dealing with fifos.
 
 How to properly fix this, I don't know.  But the issue seems to be
 quite serious.
 
 (For future reference, kern/8151 and kern/30401 report similar issues.)
 
 -- 
 Julio M. Merino Vidal <jmmv84@gmail.com>
 The Julipedia - http://julipedia.blogspot.com/