>The problem is a dangling pointer left in the lockf structure belonging to
>the current lock holder. The offending process frees its lock structure
>after breaking out of sleep() as a result of a signal. Possible fix:
>scan the list of waiting locks to remove the lock that isn't going to be
>used.
Unfortunately, the fix that went with it was totally bogus. This one might
do a better job:
Date: Mon, 26 Apr 1993 17:05:01 GMT
AUTHOR: Paul Kranenburg (pk@cs.few.eur.nl)
386BSD-Patchkit: patch00169
* SUCH DAMAGE.
*
* @(#)ufs_lockf.c 7.7 (Berkeley) 7/2/91
* SUCH DAMAGE.
*
* @(#)ufs_lockf.c 7.7 (Berkeley) 7/2/91
+ *
+ * PATCHES MAGIC LEVEL PATCH THAT GOT US HERE
+ * -------------------- ----- ----------------------
+ * CURRENT PATCH LEVEL: 1 00169
+ * -------------------- ----- ----------------------
+ *
+ * 04 Jun 93 Paul Kranenburg Fix dangling pointer in lockf struct
+ *
}
#endif /* LOCKF_DEBUG */
if (error = tsleep((caddr_t)lock, priority, lockstr, 0)) {
}
#endif /* LOCKF_DEBUG */
if (error = tsleep((caddr_t)lock, priority, lockstr, 0)) {
+
+ /* Don't leave a dangling pointer in block list */
+ if (lf_getblock(lock) == block) {
+ struct lockf **prev;
+
+ /* Still there, find us on list */
+ prev = &block->lf_block;
+ while ((block = block->lf_block) != NOLOCKF) {
+ if (block == lock) {
+ *prev = block->lf_block;
+ break;
+ }
+ prev = &block->lf_block;
+ }
+ }
free(lock, M_LOCKF);
return (error);
}
free(lock, M_LOCKF);
return (error);
}