On Mon, Dec 19, 2011 at 04:06:51AM +0000, Christos Zoulas wrote: > In article <20111219033403.ga25...@panix.com>, > Thor Lancelot Simon <t...@panix.com> 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
