>Number:         11064
>Category:       kern
>Synopsis:       lfs_tuncate: truncate to 0 but -2 blocks on inode
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Sep 21 13:27:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Manuel Bouyer
>Release:        -1.5_ALPHA, updated a few days ago (after lfs pullups)
>Organization:

myself

>Environment:
	
System: NetBSD rochebonne.antioche.eu.org 1.5_ALPHA2 NetBSD 1.5_ALPHA2 (ROCHEBONNE) #0: Fri Sep 15 20:24:22 MEST 2000 bouyer@rochebonne.antioche.eu.org:/mnt/1.5/src/sys/arch/i386/compile/ROCHEBONNE i386

>Description:
	After the recent LFS fixes I tried to stress it again.
	Running the following scripts in parallel leads to the panic described
	below:
	script1:
	#! /bin/csh
	while(1)
	echo rm
	rm -rf tst/*
	end

	script2:
	#! /bin/csh
	while(1)
	echo cp
	pax -rw 1.5 tst
	end

	In the current directory I have:
	tst : a directory, used for the test
	1.5: 1.5_ALPHA2 source tree (with the objects created by an interrupted
	'make build').
	All this on a celeron 500 box , the LFS is on a raid-1 filesystem
	spread accross 4 IDE drives (each drive on its own channel).
	So the test is to copy the build tree to a test directory, and at the
	same time 'rm -rf'ing the tree pax is creating. The goal is to create
	race conditions. No need to run this as root to reproduce the
	problem.

	After a while the system panics with:
lfs_tuncate: truncate to 0 but -2 blocks on inode
panic: lfs_truncate: persistent blocks

Stopped in rm at        cpu_Debugger+0x4:       leave
db> tr
cpu_Debugger(2,3,c06e7000,d6cbde5c,c025665b) at cpu_Debugger+0x4
panic(c02fa700,c02fa6c0,fffffffe,2b,d6b8adf8) at panic+0x64
lfs_truncate(d6cbde80,d6cbdee0,0,d6b5c0d0,d6cbdf18) at lfs_truncate+0xd97
ufs_rmdir(d6cbdee0,d6cbdee0,d6b8bd30,d6cbdecc,6b7eebca) at ufs_rmdir+0x1bb
lfs_rmdir(d6cbdee0,d6cbdf88,d6ccb800,d6cbdf80,c032a580) at lfs_rmdir+0xf7
sys_rmdir(d6ccb800,d6cbdf88,d6cbdf80,0,808a000) at sys_rmdir+0x10c
syscall() at syscall+0x200
--- syscall (number 137) ---

After reboot, fsck_lfs doesn't show anything wrong on the LFS, only avail not
being correct.

>How-To-Repeat:
	see above
>Fix:
	Well, don't do this ? :)
>Release-Note:
>Audit-Trail:
>Unformatted: