Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site unmvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!hogpc!houti!ariel!vax135!floyd!cmcl2!lanl-a!unm-cvax!unmvax!lee
From: lee@unmvax.UUCP
Newsgroups: net.bugs.4bsd
Subject: 4.2 BSD occasionally trashes files
Message-ID: <314@unmvax.UUCP>
Date: Mon, 30-Apr-84 04:30:31 EDT
Article-I.D.: unmvax.314
Posted: Mon Apr 30 04:30:31 1984
Date-Received: Tue, 1-May-84 07:56:47 EDT
Organization: Univ. of New Mexico, Albuquerque
Lines: 42

Subject: 4.2BSD occasionally trashes files
Newsgroups: net.bugs.4bsd

Subject: UNIX 4.2 BSD trashes files
Index:	4.2BSD kernel

Description:
	Occasionally files will get trashed. This was reported
	earlier but the only "fix" was a stop-gap measure which controlled
	the bug by issuing a panic. These mods were made to iput() and
	closef().
Repeat-By:
	Hard to, it looks to be a race condition.
Fix:
	The routine irele() would lock an inode without first checking
	to see if such was already locked. Below is a diff of
	/sys/sys/ufs_inode.c. I suggest you leave in those panics
	for awhile just to make sure....

RCS file: RCS/ufs_inode.c,v
retrieving revision 1.2
diff  -r1.2 ufs_inode.c
2c2
<  * $Header: ufs_inode.c,v 1.2 84/02/12 22:47:45 root Exp $
---
>  * $Header: ufs_inode.c,v 1.3 84/04/30 02:12:19 root Exp $
3a4,11
>  * Revision 1.3  84/04/30  02:12:19  root
>  * Think I found the bug with trashed files that the stop gap measure
>  * (the panic in iput() and closef()) controlled. In irele() it locks
>  * the inode but does not check to see if it has already been locked.
>  * I am leaving in the stop-gap panics for now but we should know
>  * for sure in a month.
>  * 				--Lee
>  * 
252c260
< 		ip->i_flag |= ILOCKED;
---
> 		ilock(ip);
-- 
			--Lee (Ward)
			{ucbvax,convex,gatech,pur-ee}!unmvax!lee