From owner-freebsd-current Fri Aug 2 11:05:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA19939 for current-outgoing; Fri, 2 Aug 1996 11:05:08 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA19934 for ; Fri, 2 Aug 1996 11:05:05 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA05977; Fri, 2 Aug 1996 11:03:10 -0700 From: Terry Lambert Message-Id: <199608021803.LAA05977@phaeton.artisoft.com> Subject: Re: NFS Diskless Dispare... To: dfr@render.com (Doug Rabson) Date: Fri, 2 Aug 1996 11:03:10 -0700 (MST) Cc: terry@lambert.org, jkh@time.cdrom.com, tony@fit.qut.edu.au, freebsd-current@freebsd.org In-Reply-To: from "Doug Rabson" at Aug 2, 96 06:06:44 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > > > > 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. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.