[4469] in Athena Bugs
re: NFS server panic: protection fault
daemon@ATHENA.MIT.EDU (John T Kohl)
Thu Mar 8 13:35:06 1990
Date: Thu, 8 Mar 90 13:34:37 -0500
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
To: bugs@ATHENA.MIT.EDU, jfc@ATHENA.MIT.EDU, dkk@ATHENA.MIT.EDU
In-Reply-To: [4467]
There is indeed a race between two nfsd's which can cause the system
crashes we have observed.
One process takes a free (but dirty) in-core inode & starts playing with
it, but neither locks the inode nor cleans out the fields used to
identify the associated on-disk inode. It then puts the inode onto a
hash list.
While it is cleaning up the old contents of the inode (pushing quota
information to disk), another process comes along and finds this inode
in a hash chain, and starts using it as if it were still valid. While
it's doing this, it derefs a null pointer and crashes the machine.
This scenario can happen in the 4.3BSD and 4.3BSD-tahoe sources as well,
although the likelihood is much lower in those cases, since the lock is
grabbed before the process pushes quota information to disk (which is
likely to relinquish the processor in an I/O wait).
The frequency of occurence is probably highly dependent on system table
sizes and patterns of usage, as it requires that a freed in-core inode be
grabbed just as another process/user wants to use the in-core inode's former
contents.
This all happens in ufs_inode.c:iget(), and can probably be solved by
improving the locking strategy somewhat.
John
