Subject: nullfs and panic: locking against myself
To: None <current-users@NetBSD.ORG>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: current-users
Date: 01/03/1998 11:39:59
I'm running NetBSD/sparc on a SS1+, with everything built from sources
supped on December 31st.  I was using nullfs mounts to allow pieces of
the filesystem space to share a partition, as in

	/dev/sd0e /big ffs rw 1 2
	/big/home /home null rw 0 0
	/big/local /local null rw 0 0
	/big/sources /sources null rw 0 0

I was working in /sources, doing a find in the background with output
to a file and simultaneously doing a number of cp commands, as in

	% find latest-usr-src .... > a-file &
	% ( cd ... ; find . -type f -print ) | sh -c 'while read fn; do cp .../$fn .../$fn; done'

After copying a handful of files, the thing panicked with "locking
against myself".  After struggling with gdb "target kcore" not starting
out with the process that crashed, ps(1) documenting a field name
(uprocp) that doesn't exist and not documenting the necessary high two
nibbles for -O paddr (f0, which I guessed based on "nm /netbsd"), I
managed to get a stack trace out of gdb:

	% ps ax -M netbsd.0.core -N netbsd.0 -O paddr
	  446 710c00  a  R      0:24:21 (find)
	(gdb) proc 0xf0710c00
	(gdb) where
	#0  0xf012b504 in dumpsys ()
	#1  0xf012b2a0 in cpu_reboot ()
	#2  0xf003d200 in panic ()
	#3  0xf00e0688 in ufs_lock ()
	#4  0xf0061fec in null_lock ()
	#5  0xf0062380 in null_lookup ()
	#6  0xf0056898 in lookup ()
	#7  0xf0056280 in namei ()
	#8  0xf005ba60 in sys___lstat13 ()
	#9  0xf013aec8 in syscall ()

For now, I'm simply using symlinks instead of nullfs mounts.  But I'd
thought someone had gone through and fixed nullfs's locking...if so,
I'd say it's not quite as fixed as it should have been.  I still have
the coredump, if anyone would like a copy, or can suggest anything I
could do to pull more useful information out of it.

					der Mouse

		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B