Re: cloning device close race?

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Sun, 18 Dec 2011 22:34:03 -0500
Thor Lancelot Simon <tls%panix.com@localhost> wrote:

> If you run 10 or so copies at once on a multiprocessor system
> with DIAGNOSTIC, you'll see a lot of this message emitted:
> 
> vrelel: missing VOP_CLOSE(): vnode @ 0xfffffe801e73cb28, flags 
> (0x800030<MPSAFE,LOCKSWORK,INACTNOW>)
>       tag VT_UFS(1), type VCHR(4), usecount 2, writecount 0, holdcount 0
>       freelisthd 0x0, mount 0xffff800024235000, data 0xfffffe801de01f00 lock 
> 0xfffffe801e73cc38
>       tag VT_UFS, ino 46213, on dev 4, 0 flags 0x0, nlink 1
>       mode 020644, owner 0, group 0, size 0
> 
> I am guessing the problem also exists with other cloning
> pseudodevices, not just the new /dev/random implementation.

This just reminds me that a friend yesterday pointed me to this article
about close(2)'s POSIX semantics:

http://www.daemonology.net/blog/2011-12-17-POSIX-close-is-broken.html

I then only checked the close(2) manual page so far, which indeed lists
EINTR as a possible errno value on error.  But since the article also
mentions that some OSs decided to ensure that EINTR never be returned
to avoid the problems, I wondered: does NetBSD already do something to
ensure that either: 1) EINTR not be possible or atomically be restated
transparently in the same LWP, or 2) the state of an FD after an
interrupted close(2) never be inconsistent?  The latter solution might
still allow race conditions in multithreaded code, possibly.

Thanks,
-- 
Matt