Subject: Re: nfsd: locking botch in op %d
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Bill Studenmund <email@example.com>
Date: 03/13/2001 16:59:52
On Tue, 13 Mar 2001, der Mouse wrote:
> > Except you upgraded. :-)
> I don't *think* so. I've been using 2000-02-19 sources since, well,
> February last year. And I set up that NFS server a matter of weeks
> ago. I find it difficult to believe I had a kernel a year old still
> kicking around.
> What's more, I don't think I touched *anything* on the server between
> setting it up and noticing the crash.
> Well, not that it matters much.
Something must have changed in your usage traffic pattern. Though I'm not
sure what. :-(
> > If you can, please try it.
> I probably can. Would you rather I make the no* routines do real
> locking, or that I change specfs's vnopeops to use the real-locking
> Do you also want me to back out the VOP_UNLOCK I added? (Presumably,
> since otherwise, what's to tell whether it works?)
Actually, I like what you did better for now. :-)
> >> What I did do, and it seems to have made the problem go away, is
> >> +++ ufs_vnops.c Tue Mar 13 01:00:13 2001
> >> + VOP_UNLOCK(vp,0);
> > That actually is the other way to fix the problem, though with doing
> > this the vput really should be a vrele() (since otherwise you're
> > implicitly relying on specfs using the nolock routines :-)
> Ah, now, that's the sort of thing I meant when I wrote of someone
> actually understanding the code. :-)
> > We either: 1) [...], 2) [...], or 3) [...]
> Actually, why mess with the v_op pointer at all? (I don't understand
> the code enough to see why that's being done.)
Since the vnode we made we're now dis-assosiating with our file system.
Since it is a semi-live vnode, it does need _something_ that works in its
v_op pointer. So we use the spec_vnodep_p table. :-)