Re: panic: System call lstat returning with 1 locks held

On Wed, Feb 06, 2008 at 03:57:58PM +0100, Attilio Rao wrote:
> 2008/2/6, Attilio Rao <attilio_at_freebsd.org>:
> > 2008/2/6, Yar Tikhiy <yar_at_comp.chem.msu.su>:
> >
> > > On Wed, Feb 06, 2008 at 02:49:49PM +0100, Attilio Rao wrote:
> >  >  [...]
> >  >
> >  > > Want to see if this bt has been helpful? :)
> >  >  > Can you try the attached patch and see if kernel rings a bell?:
> >  >  > http://www.freebsd.org/~attilio/ntfs_debug.diff
> >  >
> >  >
> >  > The kernel just panics. :-)
> >
> >
> > This is the new I wanted to know! :)
> >  With better checks in lockmgr code, we would have caught more
> >  informations about it.
> >
> >  Can you please now add DDB support and once it breaks in DDB do a
> >  'show alllocks' and maybe other small investigations?
> >  This should shade a light for us.
> 
> Could you please enable NTFS_DEBUG too and maybe see, when the kernel
> panics, what is the value of i_usecount for the specified ip?
> I want to exclude refcount leaking.

i_usecount is just zero for the faulty ip:

(kgdb) bt
#0  doadump () at pcpu.h:195
#1  0xc07680de in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:417
#2  0xc07683a3 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:571
#3  0xc048e507 in db_panic (addr=Could not find the frame base for "db_panic".
) at /usr/src/sys/ddb/db_command.c:444
#4  0xc048ef0c in db_command (last_cmdp=0xc0bdd194, cmd_table=0x0, dopager=1)
    at /usr/src/sys/ddb/db_command.c:411
#5  0xc048f01a in db_command_loop () at /usr/src/sys/ddb/db_command.c:464
#6  0xc04907bd in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:228
#7  0xc07913b6 in kdb_trap (type=3, code=0, tf=0xd614e9fc)
    at /usr/src/sys/kern/subr_kdb.c:510
#8  0xc0a5dedb in trap (frame=0xd614e9fc) at /usr/src/sys/i386/i386/trap.c:647
#9  0xc0a438cb in calltrap () at /usr/src/sys/i386/i386/exception.s:146
#10 0xc079153a in kdb_enter (why=0xc0af0f54 "panic", msg=0xc0af0f54 "panic")
    at cpufunc.h:60
#11 0xc076838c in panic (fmt=0xc0aee673 "lockmgr still held")
    at /usr/src/sys/kern/kern_shutdown.c:555
#12 0xc0755abe in lockdestroy (lkp=0xc0af0f54)
    at /usr/src/sys/kern/kern_lock.c:574
#13 0xc2ff8688 in ntfs_ntput (ip=0xc2fbba00)
    at /usr/src/sys/modules/ntfs/../../fs/ntfs/ntfs_subr.c:467
#14 0xc2ff5eb8 in ntfs_reclaim (ap=0xd614eb04)
    at /usr/src/sys/modules/ntfs/../../fs/ntfs/ntfs_vnops.c:262
[...]
(kgdb) frame 13
#13 0xc2ff8688 in ntfs_ntput (ip=0xc2fbba00)
    at /usr/src/sys/modules/ntfs/../../fs/ntfs/ntfs_subr.c:467
467             lockdestroy(&ip->i_lock);
(kgdb) p *ip
$2 = {i_devvp = 0xc2fe2dd0, i_dev = 0xc2e7de00, i_hash = {le_next = 0x0,
    le_prev = 0xc302002c}, i_next = 0x0, i_prev = 0x0, i_mp = 0xc2fbb500,
  i_number = 10, i_flag = 32768, i_lock = {lk_object = {
      lo_name = 0xc2ffb672 "ntnode", lo_type = 0xc2ffb672 "ntnode",
      lo_flags = 91947008, lo_witness_data = {lod_list = {
          stqe_next = 0xc0c21190}, lod_witness = 0xc0c21190}},
    lk_interlock = 0xc0c0dbe8, lk_flags = 262144, lk_sharecount = 0,
    lk_waitcount = 0, lk_exclusivecount = 1, lk_prio = 72, lk_timo = 0,
    lk_lockholder = 0xc2fecaa0, lk_newlock = 0x0}, i_interlock = {
    lock_object = {lo_name = 0xc2ffc039 "ntnode interlock",
      lo_type = 0xc2ffc039 "ntnode interlock", lo_flags = 16908288,
      lo_witness_data = {lod_list = {stqe_next = 0xc0c21168},
        lod_witness = 0xc0c21168}}, mtx_lock = 6, mtx_recurse = 0},
  i_usecount = 0, i_fnlist = {lh_first = 0x0}, i_valist = {lh_first = 0x0},
  i_nlink = 1, i_mainrec = 0, i_frflag = 1}

-- 
Yar