Bug #1196
closed
mount_null twice in a row panics
0%
Description
Hi,
doing (for example) 'mount_null /usr /mnt' twice in a row panics the
box. Backtrace attached. I can send a dump but it's reliably reproducible.
Regards,
Sascha
Current directory is /var/crash/
Unread portion of the kernel message buffer:
panic: lockmgr: locking against myself
Trace beginning at frame 0xd5ea2afc
panic(d5ea2b20,c2b323a8,0,0,d5ea2b30) at panic+0x8c
panic(c058671c,d5a34100,20000,c2b323a8,20002) at panic+0x8c
lockmgr(c2b323a8,20002) at lockmgr+0x2f9
vn_lock(c2b322e8,20002,c2b322e8,c2b322e8,d2b2e3e8) at vn_lock+0x21
vget(c2b322e8,20002,d2b2e3e0,d5ea2cc4,c033125b) at vget+0x25
nullfs_root(d2b2e1d8,d5ea2bb8) at nullfs_root+0x1b
sys_mount(d5ea2cf0,6,0,0,d2b2dd58) at sys_mount+0x7b9
syscall2(d5ea2d40) at syscall2+0x1ef
Xint0x80_syscall() at Xint0x80_syscall+0x36
Debugger("panic")
panic: from debugger
Uptime: 5m54s
dumping to dev #ad/0x20001, blockno 2097456
dump ...
GNU gdb 6.7.1
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-dragonfly".
(kgdb) bt
#0 dumpsys () at ./machine/thread.h:83
#1 0xc02e21d6 in boot (howto=260)
at /home/s/projects/dragonfly/src/sys/kern/kern_shutdown.c:376
#2 0xc02e22f7 in panic (fmt=0xc053bcf6 "from debugger")
at /home/s/projects/dragonfly/src/sys/kern/kern_shutdown.c:801
#3 0xc01662b5 in db_panic (addr=-1068661196, have_addr=0, count=-1,
modif=0xd5ea29b0 "")
at /home/s/projects/dragonfly/src/sys/ddb/db_command.c:447
#4 0xc0166920 in db_command_loop ()
at /home/s/projects/dragonfly/src/sys/ddb/db_command.c:343
#5 0xc0168ef4 in db_trap (type=3, code=0)
at /home/s/projects/dragonfly/src/sys/ddb/db_trap.c:71
#6 0xc04d8787 in kdb_trap (type=3, code=0, regs=0xd5ea2aa8)
at
/home/s/projects/dragonfly/src/sys/platform/pc32/i386/db_interface.c:148
#7 0xc04e9c09 in trap (frame=0xd5ea2aa8)
at /home/s/projects/dragonfly/src/sys/platform/pc32/i386/trap.c:815
#8 0xc04d9497 in calltrap ()
at
/home/s/projects/dragonfly/src/sys/platform/pc32/i386/exception.s:785
#9 0xc04d8634 in Debugger (msg=0xc0552292 "panic") at ./cpu/cpufunc.h:73
#10 0xc02e22ee in panic (fmt=0xc058671c "lockmgr: locking against myself")
at /home/s/projects/dragonfly/src/sys/kern/kern_shutdown.c:799
#11 0xc02d75a9 in lockmgr (lkp=0xc2b323a8, flags=131074)
at /home/s/projects/dragonfly/src/sys/kern/kern_lock.c:348
#12 0xc0332546 in vn_lock (vp=0xc2b322e8, flags=131074)
at /home/s/projects/dragonfly/src/sys/kern/vfs_vnops.c:1069
#13 0xc032b41d in vget (vp=0xc2b322e8, flags=18)
at /home/s/projects/dragonfly/src/sys/kern/vfs_lock.c:356
#14 0xd58f7c2a in ?? ()
#15 0xc033125b in sys_mount (uap=0xd5ea2cf0)
at /home/s/projects/dragonfly/src/sys/kern/vfs_syscalls.c:444
#16 0xc04e95ba in syscall2 (frame=0xd5ea2d40)
at /home/s/projects/dragonfly/src/sys/platform/pc32/i386/trap.c:1357
#17 0xc04d9546 in Xint0x80_syscall ()
at
/home/s/projects/dragonfly/src/sys/platform/pc32/i386/exception.s:876
#18 0x080493a8 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Updated by nthery almost 16 years ago
Can you still reproduce it?
I didn't manage to with both HEAD as of just after the migration to
git and HEAD as of 30 minutes ago.
Cheers,
Nicolas
Updated by swildner almost 16 years ago
Yes it's reproducible still. Could it be that it happens because this is
a HAMMER filesystem and /usr is already a null mount?
Sascha
Updated by Johannes.Hofmann almost 16 years ago
I just tried it in a vkernel and the problem occurs if the
null-mounted directory is on HAMMER.
In that case during the second mount_null call,
VFS_ROOT(mp, &newdp) called from checkdirs() in turn called from sys_mount()
tries to acquire the same lock, that was already acquired by vn_lock()
from sys_mount() directly.
Doing checkdirs() after vn_unlock(vp) makes the problem go away, but
of course it might not be allowed to call checkdirs() without the lock
protection.
Johannes
Updated by dillon almost 16 years ago
:Johannes Hofmann <Johannes.Hofmann@gmx.de> added the comment:
:
:I just tried it in a vkernel and the problem occurs if the
:null-mounted directory is on HAMMER.
:In that case during the second mount_null call,
:
:VFS_ROOT(mp, &newdp) called from checkdirs() in turn called from sys_mount(=
:)=20
:tries to acquire the same lock, that was already acquired by vn_lock()
:from sys_mount() directly.
:
:Doing checkdirs() after vn_unlock(vp) makes the problem go away, but
:of course it might not be allowed to call checkdirs() without the lock
:protection.
:
: Johannes
Hmm. I think we can safely call checkdirs() without the lock
protection as long as the vnode still has a ref, which it does.
The cache entries are still locked.I will commit the change, we should be able to get enough testing
in prior to the release.-Matt
Updated by swildner almost 16 years ago
Fixed per Matt's commit:
http://leaf.dragonflybsd.org/mailarchive/commits/2009-01/msg00207.html