Bug #1138
closed
HAMMER: panic: lockmgr: locking against myself
0%
Description
I get this panic consistently after 5-20 minutes when doing buildworld,
using nfs mount for /usr/src & /usr/obj and using hammer on nfs server.
Crash dump on leaf in crash/hammer/ask/*.13.
HAMMER PFSs are not used on nfs server
(unlike <https://bugs.dragonflybsd.org/issue1125>).
Retesting got another panic (like .13); on bootup a third panic occurred just after HAMMER:
*.14 and *.15 being uploaded to leaf.
thomas
#0 dumpsys () at ./machine/thread.h:83
#1 0xc02c64da in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:375
#2 0xc02c65fb in panic (fmt=0xc05235b7 "from debugger") at /usr/src/sys/kern/kern_shutdown.c:800
#3 0xc01648f5 in db_panic (addr=-1068756004, have_addr=0, count=-1, modif=0xc9dc53f8 "")
at /usr/src/sys/ddb/db_command.c:447
#4 0xc0164f60 in db_command_loop () at /usr/src/sys/ddb/db_command.c:343
#5 0xc01674d8 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:71
#6 0xc04c152f in kdb_trap (type=3, code=0, regs=0xc9dc54f0)
at /usr/src/sys/platform/pc32/i386/db_interface.c:148
#7 0xc04d2db6 in trap (frame=0xc9dc54f0) at /usr/src/sys/platform/pc32/i386/trap.c:842
#8 0xc04c2247 in calltrap () at /usr/src/sys/platform/pc32/i386/exception.s:785
#9 0xc04c13dc in Debugger (msg=0xc0537b00 "panic") at ./cpu/cpufunc.h:73
#10 0xc02c65f2 in panic (fmt=0xc0567370 "lockmgr: locking against myself")
at /usr/src/sys/kern/kern_shutdown.c:798
#11 0xc02bba9c in lockmgr (lkp=0xc12cf4e4, flags=131074) at /usr/src/sys/kern/kern_lock.c:348
#12 0xc02fc841 in regetblk (bp=0xc12cf3cc) at /usr/src/sys/sys/buf2.h:83
#13 0xc0430fdd in hammer_io_release (io=0xc9f8b680, flush=0)
at /usr/src/sys/vfs/hammer/hammer_io.c:359
#14 0xc043816a in hammer_rel_buffer (buffer=0xc9f8b680, flush=0)
at /usr/src/sys/vfs/hammer/hammer_ondisk.c:871
#15 0xc0431590 in hammer_io_inval (volume=0xc11707b0, zone2_offset=2305843240093351936)
at /usr/src/sys/vfs/hammer/hammer_io.c:278
#16 0xc0438f33 in hammer_del_buffers (hmp=0xc9b13000, base_offset=2305843240093351936,
zone2_offset=2305843240093351936, bytes=8388608) at /usr/src/sys/vfs/hammer/hammer_ondisk.c:730
#17 0xc0425c3e in hammer_blockmap_reserve_complete (hmp=0xc9b13000, resv=0xc77d08b8)
at /usr/src/sys/vfs/hammer/hammer_blockmap.c:594
#18 0xc0433b87 in hammer_rel_mem_record (record=0xca7ca368)
at /usr/src/sys/vfs/hammer/hammer_object.c:434
#19 0xc04345b6 in hammer_ip_add_bulk (ip=0xca9ce448, file_offset=0, data=0xc15e0000, bytes=6688,
errorp=0xc9dc57e8) at /usr/src/sys/vfs/hammer/hammer_object.c:903
#20 0xc04401cd in hammer_vop_strategy (ap=0xc9dc5804)
at /usr/src/sys/vfs/hammer/hammer_vnops.c:2611
#21 0xc0316e62 in vop_strategy (ops=0xc11f9af8, vp=0xca49db90, bio=0xc12bd5c4)
at /usr/src/sys/kern/vfs_vopops.c:659
#22 0xc02fbabe in vn_strategy (vp=0xc066da0c, bio=0x7020) at /usr/src/sys/kern/vfs_bio.c:3089
#23 0xc02ff0fe in bwrite (bp=0xc12bd594) at /usr/src/sys/kern/vfs_bio.c:797
#24 0xc044160e in hammer_vop_write (ap=0xc9dc58d4) at /usr/src/sys/vfs/hammer/hammer_vnops.c:517
#25 0xc0316ebe in vop_write (ops=0xc11f9af8, vp=0xca49db90, uio=0xc9dc5954, ioflag=12,
cred=0xc11dcf98) at /usr/src/sys/kern/vfs_vopops.c:351
#26 0xc038f304 in nfsrv_write (nfsd=0xc11dcf18, slp=0xc11fef58, td=0xc11da038, mrq=0xc9dc5bac)
at /usr/src/sys/vfs/nfs/nfs_serv.c:1105
#27 0xc039b871 in sys_nfssvc (uap=0xc9dc5cf0) at /usr/src/sys/vfs/nfs/nfs_syscalls.c:590
Updated by dillon about 16 years ago
:I get this panic consistently after 5-20 minutes when doing buildworld,
:using nfs mount for /usr/src & /usr/obj and using hammer on nfs server.
:
:Crash dump on leaf in crash/hammer/ask/*.13.
:
:HAMMER PFSs are not used on nfs server
:(unlike <https://bugs.dragonflybsd.org/issue1125>).
:
:Retesting got another panic (like .13); on bootup a third panic occurred ju=
:st after HAMMER:
:*.14 and *.15 being uploaded to leaf.
*.14 looks corrupt. *.13 and *.15 look good. They appear to be the
same panic.Ok, please try this patch. It is a second bug in the same code path
from a week ago (note this folds in that other patch too, which changed
the KKASSERT).-Matt
Matthew Dillon
<dillon@backplane.com>Index: hammer_io.c
===================================================================
RCS file: /cvs/src/sys/vfs/hammer/hammer_io.c,v
retrieving revision 1.54
diff u -p -r1.54 hammer_io.c hammer_io.c 29 Aug 2008 20:19:08
--0000 1.54>io.lock);
++ hammer_io.c 13 Sep 2008 18:12:34 -0000@ -277,17 +277,19 @ hammer_io_inval(hammer_volume_t volume,
hammer_ref(&iou
hammer_io_clear_modify(&iou->io, 1);
bundirty(bp);
iou->io.released = 0;
+ BUF_KERNPROC(bp);
iou->io.reclaim = 1;
iou->io.waitdep = 1;
- KKASSERT(iou->io.lock.refs 0);
+ KKASSERT(iou->io.lock.refs 1);
hammer_rel_buffer(&iou->buffer, 0);
/*hammer_io_deallocate(bp);*/
} else {
KKASSERT == 0);
bundirty(bp);
bp->b_flags |= B_NOCACHE|B_RELBUF;
+ brelse(bp);
}
- brelse(bp);
crit_exit();
}
Index: hammer_object.c
===================================================================
RCS file: /cvs/src/sys/vfs/hammer/hammer_object.c,v
retrieving revision 1.96
diff u -p -r1.96 hammer_object.c hammer_object.c 9 Aug 2008 07:04:16
--0000 1.96>flags & HAMMER_RECF_INTERLOCK_BE) {
++ hammer_object.c 13 Sep 2008 17:55:08 -0000@ -897,9 +897,9 @ hammer_ip_add_bulk(hammer_inode_t ip, of
if (conflict
conflict->flags |= HAMMER_RECF_WANTED;
tsleep(conflict, 0, "hmrrc3", 0);
- } else {
- conflict->flags |= HAMMER_RECF_DELETED_FE;
continue;
}
+ conflict->flags |= HAMMER_RECF_DELETED_FE;
hammer_rel_mem_record(conflict);
}
Updated by thomas.nikolajsen about 16 years ago
Patch (issue1139) solved problem.