On Fri, Sep 26, 2008 at 09:20:33PM +1000, David Cecil wrote:
> 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.
No, it should be fixed. See

r168020 | kib | 2007-03-29 11:21:09 +0300 (Thu, 29 Mar 2007) | 7 lines
Extend rev. 1.210 to avoid dereference NULL mp in VFS_NEEDSGIANT and
VFS_ASSERT_GIANT. Stop using reserved namespace.

and

r158320 | tegge | 2006-05-05 22:32:35 +0300 (Fri, 05 May 2006) | 2 lines
Avoid dereferencing NULL pointer.

>
> 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
>
>
> _______________________________________________
> freebsd-fs@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)

iEYEARECAAYFAkjcze4ACgkQC3+MBN1Mb4jiKwCfa3gSRFZ+0+ 58t9hyzq7lGVSE
v9cAn3Bk0jAXDFbndo8ZtEfZaYJL4trg
=A4zl
-----END PGP SIGNATURE-----

Ah yes, thanks Kostik I looked at that change, it didn't immediately
click. After you mentioned it the local variable made sense.

Thanks for pointing it out.

Dave

ext Kostik Belousov wrote:
> On Fri, Sep 26, 2008 at 09:20:33PM +1000, David Cecil wrote:
>
>> 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.
>>
> No, it should be fixed. See
>
> r168020 | kib | 2007-03-29 11:21:09 +0300 (Thu, 29 Mar 2007) | 7 lines
> Extend rev. 1.210 to avoid dereference NULL mp in VFS_NEEDSGIANT and
> VFS_ASSERT_GIANT. Stop using reserved namespace.
>
> and
>
> r158320 | tegge | 2006-05-05 22:32:35 +0300 (Fri, 05 May 2006) | 2 lines
> Avoid dereferencing NULL pointer.
>
>
>> 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
>>
>>
>> _______________________________________________
>> freebsd-fs@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
>>
_______________________________________________
freebsd-fs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"