On Sun, 18 Dec 2011 22:34:03 -0500 Thor Lancelot Simon <t...@panix.com> 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