panic in closef
David Cecil
david.cecil at nokia.com
Fri Sep 26 11:45:08 UTC 2008
Hi,
I'm debugging a panic with the call trace below. This is from a
6.1-based kernel, but as far as I can tell there are no fixes for this
problem in current, based on where I think the problem lies.
It falls over in the call to VFS_LOCK_GIANT in closef, trying to
dereference a NULL mount point. To me, the check in VFS_NEEDSGIANT
looks flawed; it checks that MP isn't NULL, then dereferences it, but
I'd expect the vnode interlock to be held (or similar), but it isn't
based on what I see of the code.
I looks to me like vgonel was probably running around the same time. It
calls delmntque and NULLs v_mount. I can't see how these two threads
are synchronised to prevent the race condition I describe, but maybe I'm
missing something.
Any ideas?
Thanks,
Dave
Unread portion of the kernel message buffer:
2
panic: page fault
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper(60794d20) at db_trace_self_wrapper+0x25
kdb_backtrace(f8d0eae8,100,67aeb640,28,f8d0eb64,...) at kdb_backtrace+0x29
panic(60774fbe,607bae69,0,fffff,681dc89b,...) at panic+0x230
trap_fatal(f8d0eb64,6f,67aeb640,0,c,...) at trap_fatal+0x2ce
trap_pfault(f8d0eb64,0,6f) at trap_pfault+0x1ef
trap(7ae70008,28,f8d00028,3,8236e104,...) at trap+0x36d
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0x60565e72, esp = 0xf8d0eba4, ebp = 0xf8d0ec00 ---
closef(7d7f19cc,67aeb640) at closef+0x36
fdfree(67aeb640) at fdfree+0x5a7
exit1(67aeb640,100,f8d0ed30,6074c903,67aeb640,...) at exit1+0x4ee
exit1(67aeb640,f8d0ed04) at exit1
syscall(5fbf003b,812003b,5fbf003b,0,0,...) at syscall+0x2b7
Xint0x80_syscall() at Xint0x80_syscall+0x1f
More information about the freebsd-fs
mailing list