[4489] in Athena Bugs
NFS server panic's (protection faults)
daemon@ATHENA.MIT.EDU (John T Kohl)
Sat Mar 10 10:25:41 1990
Date: Sat, 10 Mar 90 10:25:08 EST
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
To: bugs@ATHENA.MIT.EDU
Again, this code is in ufs_inode.c. The inode lock should be set before
the dqrele() call.
In-reply-to: jtkohl@MIT.EDU's message of 9 Mar 90 09:30:46
Newsgroups: comp.bugs.4bsd
Subject: Re: ufs_inode.c:iget() locking race condition?
References: <1990Mar9.143127.24572@athena.mit.edu>
Distribution:
--text follows this line--
In article <1990Mar9.143127.24572@athena.mit.edu> I wrote:
> There seems to be a race condition which is rarely hit in stock 4.3BSD
> or 4.3BSD-tahoe systems, but is hit often with our NFS implementation
> (due to a bit of code rearrangement).
The race is real, but I failed to adequately express my suspicions in
the previous post.
The problem is that the locks aren't held at the appropriate times, and
this causes problems not because of involuntary process switching, but
because one of the processes sleeps on disk I/O to update disk quota
information. This quota push is done BEFORE the inode is marked locked
in our NFS kernel, but AFTER it's locked in the 4.3Tahoe/4.3 kernel.
This is why we see the problem and you don't.
Several people pointed out in e-mail that processes which are in the
kernel doing syscall handling aren't preempted; they must relinquish the
processor or complete before the process can be switched.
