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
> routines?
> 
> 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. :-)

Take care,

Bill