Subject: Re: nfsd: locking botch in op %d
To: None <>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-kern
Date: 03/13/2001 18:29:25
>> Actually, I can't help wondering how this *ever* worked.  There was
>> a time when that diskless machine worked fine with my NFS server,
>> and I haven't changed anything since then that I can see affecting
>> this.
> 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.

>>> Could you try changing the genfs_no{,is,un}lock{,ed} calls into the
>>> real-lock varieties and see what happens?
>> I didn't try that, since [...]
> 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?)

>> 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.)

					der Mouse

		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B