Re: cloning device close race?

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Mon, Dec 19, 2011 at 04:06:51AM +0000, Christos Zoulas wrote:
> In article <20111219033403.GA25715%panix.com@localhost>,
> Thor Lancelot Simon  <tls%panix.com@localhost> wrote:
> >-=-=-=-=-=-
> >
> >I wrote the attached test program as a benchmark for the new
> >/dev/random implementation.
> >
> >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.
> 
> Does adding:
> 
>       vn_close(nd.ni_vp, flags, l->l_cred);
> 
> just after fd_dupopen in vfs_syscalls.c help? This should be right since
> the open is not associated with that vnode anymore, right?

How is this not always leaking?  Why does the DIAGNOSTIC check not catch
it more often?

Thor