panic in closef - FreeBSD

This is a discussion on panic in closef - FreeBSD ; 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. ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: panic in closef

  1. panic in closef

    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


    _______________________________________________
    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"


  2. Re: panic in closef

    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-----


  3. Re: panic in closef

    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"


+ Reply to Thread