Re: cloning device close race?

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

On Sun, 18 Dec 2011 23:40:33 -0500
Matthew Mondor <mm_lists%pulsar-zone.net@localhost> wrote:

> 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

In case someone else was also interested in this, I was informed
off-list that NetBSD ensures that the file descriptor be in closed
state after close(2), in the event where it is interrupted and errors
with EINTR.  In another discussion with the person who originally
forwarded me the above URL, I was told that according to her
investigation, Linux also does this.

Thanks,
-- 
Matt