Subject: kern/7522: panic:itrunc3
To: None <gnats-bugs@gnats.netbsd.org>
From: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
List: netbsd-bugs
Date: 05/05/1999 18:35:45
>Number:         7522
>Category:       kern
>Synopsis:       panic:itrunc3
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed May  5 18:35:00 1999
>Last-Modified:
>Originator:     Bill Sommerfeld
>Organization:
	
>Release:        199904xx
>Environment:
	
System: NetBSD orchard.arlington.ma.us 1.4A NetBSD 1.4A (ORCHARDII) #60: Tue May 4 11:31:35 EDT 1999 sommerfeld@orchard.arlington.ma.us:/usr/src/sys/arch/i386/compile/ORCHARDII i386


>Description:
system panic'ed with itrunc3 error while running "make depend"

 target kcore netbsd.17.core
panic: itrunc3
#0  0xf012dc15 in lockstatus ()
(gdb) where
#0  0xf012dc15 in lockstatus ()
#1  0xf01d6f1f in cpu_reboot ()
#2  0xf013a2d0 in log ()
#3  0xf012df7a in lockmgr ()
#4  0xf01c3ba2 in ufs_lock ()
#5  0xf0157a53 in vn_lock ()
#6  0xf01518c7 in vget ()
#7  0xf01b458b in ffs_sync ()
#8  0xf0153c24 in sys_sync ()
#9  0xf0152e82 in vfs_shutdown ()
#10 0xf01d6ef7 in cpu_reboot ()
#11 0xf013a2d0 in log ()
#12 0xf01b28f5 in ffs_truncate ()
#13 0xf01c01d1 in ufs_inactive ()
#14 0xf01519a8 in vput ()
#15 0xf01c24d9 in ufs_remove ()
#16 0xf0154f6d in sys_unlink ()
#17 0xf01e0e56 in syscall ()
#18 0xf0100e01 in syscall1 ()

currently running process appears to be a `mkdep'; the frame where the
error was detected was #12; the rest is a recursive mess due to
running back into the currently locked vnode while syncing.

panic("itrunc3") is a DIAGNOSTIC panic which appears to be triggered
if a vnode being truncated to zero length has any blocks attached to
it.

	if (length == 0 &&
	    (ovp->v_dirtyblkhd.lh_first || ovp->v_cleanblkhd.lh_first))
		panic("itrunc3");

speculation:

I may be confused, but this check appears dubious if the filesystem is
mounted async.  (because the writes of indirect blocks done by
ffs_indirtrunc() could still be ongoing.); but it looks like indirect
blocks shouldn't be written if the file is being truncated to zero
length..

Given that this is the first time I've seen this panic, this appears
difficult to reproduce.  as i don't have symbols for this kernel,
digging further may be painful.

>How-To-Repeat:
	"make depend && make" of kernel with MFS /tmp mounted async.
>Fix:
	delete test? 
	do test only if filesystem isn't async?
	i've stared at the bufcache code for a while and have not
	yet achieved enlightenment.



>Audit-Trail:
>Unformatted: