Date: Fri, 2 Aug 1996 19:52:35 +0100 (BST) From: Doug Rabson <dfr@render.com> To: Terry Lambert <terry@lambert.org> Cc: jkh@time.cdrom.com, tony@fit.qut.edu.au, freebsd-current@freebsd.org Subject: Re: NFS Diskless Dispare... Message-ID: <Pine.BSI.3.95.960802193906.21604L-100000@minnow.render.com> In-Reply-To: <199608021803.LAA05977@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2 Aug 1996, Terry Lambert wrote: > > > > > > > > I think the worst races would be between VOP_READ or VOP_WRITE and vclean. > > > > I think that you could cause real damage with one of those :-). > > > > > > I had a vclean patch to deal with the "free vnode isn't" error a long > > > time ago... it was a serious kludge, IMO, since it fixed the symptom > > > instead of the problem (which is that vclean is a bad idea). I think > > > the patch would also save us from the race conditions as well. Are you > > > maybe thinking of client side nfsnodes? > > > > I was thinking of an NFS client race where a process could be sleeping in > > NFS waiting for an rpc reply and vclean could cut in and start tearing > > thing up. If vclean manages to sleep part way through, then interesting > > things could start to happen... > > I think they would have differnt PID's. Are you concerned about the > (vp->v_flag & VXLOCK) == 0 or the !VOP_LOCK() case? > > The kernel is not currently reeentrant, and I think any underlying > FS from an export will cause the block on the server. I am thinking of the VXLOCK case. I have been trying to construct a scenario where the nfs client code ends up with an nfsnode which has been freed by vclean() due to the lack of node locks. I haven't managed it yet but I am sure there is one. There is definately a problem with multiple processes appending to a file over NFS due to nfs_write not being serialised by the lock. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 251 4411 FAX: +44 171 251 0939
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.95.960802193906.21604L-100000>