From owner-freebsd-current Fri Aug 2 11:51:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA22507 for current-outgoing; Fri, 2 Aug 1996 11:51:56 -0700 (PDT) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA22496 for ; Fri, 2 Aug 1996 11:51:47 -0700 (PDT) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id TAA01130; Fri, 2 Aug 1996 19:52:35 +0100 Date: Fri, 2 Aug 1996 19:52:35 +0100 (BST) From: Doug Rabson To: Terry Lambert cc: jkh@time.cdrom.com, tony@fit.qut.edu.au, freebsd-current@freebsd.org Subject: Re: NFS Diskless Dispare... In-Reply-To: <199608021803.LAA05977@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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