Re: SMP FFS Part 3

On Sat, 4 Dec 2004, Robert Watson wrote:

> On Sat, 4 Dec 2004, Robert Watson wrote:
> 
> > The first update of the same tree didn't cause a problem, so maybe it's
> > a path we hit the second time due to cached lookups/etc? 
> 
> A little bit more information from gdb:

FYI, got an almost identical panic installing a replacement kernel from a
build in NFS:

cc -O -pipe  -D_KERNEL -DKLD_MODULE -nostdinc -I-   -include
/data/stock/7/src/sys/i386/compile/MAC/opt_global.h -I. -I_at_
-I_at_/contrib/altq -I_at_/../include -finline-limit=8000 -fno-common -g
-I/data/stock/7/src/sys/i386/compile/MAC -mno-align-long-strings
-mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual  -fformat-extensions -std=c99 -c
/data/stock/7/src/sys/modules/3dfx/../../dev/tdfx/tdfx_pci.c
panic: lock (sleep mutex) Giant not locked _at_ kern/vfs_lookup.c:220
cpuid = 0
KDB: enter: panic
[thread pid 5462 tid 100250 ]
Stopped at      kdb_enter+0x2c: leave   
db> trace
Tracing pid 5462 tid 100250 td 0xc354f000
kdb_enter(c081ddbe,100,c354f000,c354f070,c08de5a0) at kdb_enter+0x2c
panic(c0821748,c0835631,c082e79d,c0825f81,dc) at panic+0x17f
witness_unlock(c08de5a0,8,c0825f78,dc) at witness_unlock+0x170
_mtx_unlock_flags(c08de5a0,0,c0825f78,dc) at _mtx_unlock_flags+0x3b
namei(ef326c30,84f6400,1000000,0,c275d228) at namei+0x5f0
stat(c354f000,ef326d14,2,11,282) at stat+0x4a
syscall(2f,84a002f,bfbf002f,8443401,84350dc) at syscall+0x128
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (188, FreeBSD ELF32, stat), eip = 0x82ce523, esp = 0xbfbfe15c,
ebp = 0xbfbfe3e8 ---
db> show lockedvnods
Locked vnodes
0xc275d228: tag ufs, type VDIR
    usecount 109, writecount 0, refcount 1 mountedhere 0
    flags (VV_ROOT|VV_OBJBUF)
     lock type ufs: EXCL (count 1) by thread 0xc354f000 (pid 5462)
        ino 2, on dev da0s1a (228, 6)

Looks like maybe it's the '..' transition in path lookup from a file
system that requires Giant to one that doesn't? 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert_at_fledge.watson.org      Principal Research Scientist, McAfee Research