Date: Fri, 2 Aug 1996 11:03:10 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dfr@render.com (Doug Rabson) Cc: terry@lambert.org, jkh@time.cdrom.com, tony@fit.qut.edu.au, freebsd-current@freebsd.org Subject: Re: NFS Diskless Dispare... Message-ID: <199608021803.LAA05977@phaeton.artisoft.com> In-Reply-To: <Pine.BSI.3.95.960802180338.21604K-100000@minnow.render.com> from "Doug Rabson" at Aug 2, 96 06:06:44 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608021803.LAA05977>