Project

General

Profile

Actions

Bug #1348

closed

panic: lockmgr: locking against myself

Added by hasso almost 15 years ago. Updated almost 15 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Fresh build, full hammer setup and triggered by kdesu (KDE wrapper for su
command). The panic is 100% reproduceable. Core is uploaded into leaf.

#0 dumpsys () at ./machine/thread.h:83
#1 0xc02e1f11 in boot (howto=256)
at /home/hasso/dragonfly-src/sys/kern/kern_shutdown.c:375
#2 0xc02e21d6 in panic (fmt=0xc05a2374 "lockmgr: locking against myself")
at /home/hasso/dragonfly-src/sys/kern/kern_shutdown.c:800
#3 0xc02d63dc in lockmgr (lkp=0xd5f574e8, flags=2)
at /home/hasso/dragonfly-src/sys/kern/kern_lock.c:348
#4 0xc032f843 in vx_lock (vp=0xd5f57428)
at /home/hasso/dragonfly-src/sys/kern/vfs_lock.c:306
#5 0xc032fbc7 in vnode_terminate (vp=0xd5f57428)
at /home/hasso/dragonfly-src/sys/kern/vfs_lock.c:226
#6 0xc02c0535 in _sysref_put (sr=0xd5f57438)
at /home/hasso/dragonfly-src/sys/kern/kern_sysref.c:318
#7 0xc032fa13 in vrele (vp=0x0)
at /home/hasso/dragonfly-src/sys/sys/sysref2.h:85
#8 0xc033d62c in spec_close (ap=0xd6f4f90c)
at /home/hasso/dragonfly-src/sys/vfs/specfs/spec_vnops.c:717
#9 0xc049c0c8 in hammer_vop_specclose (ap=0xd6f4f90c)
at /home/hasso/dragonfly-src/sys/vfs/hammer/hammer_vnops.c:2938
#10 0xc033875a in vop_close (ops=0xc17e9210, vp=0xd5f57428, fflag=3)
at /home/hasso/dragonfly-src/sys/kern/vfs_vopops.c:257
#11 0xc03105e7 in cttyclose (ap=0xd6f4f960)
at /home/hasso/dragonfly-src/sys/kern/tty_tty.c:151
#12 0xc02c917e in dev_dclose (dev=0xc16ea718, fflag=2, devtype=8192)
at /home/hasso/dragonfly-src/sys/kern/kern_device.c:124
#13 0xc033d684 in spec_close (ap=0xd6f4f9ac)
at /home/hasso/dragonfly-src/sys/vfs/specfs/spec_vnops.c:738
#14 0xc049c0c8 in hammer_vop_specclose (ap=0xd6f4f9ac)
at /home/hasso/dragonfly-src/sys/vfs/hammer/hammer_vnops.c:2938
#15 0xc033875a in vop_close (ops=0xc17e9210, vp=0xd64ab768, fflag=2)
at /home/hasso/dragonfly-src/sys/kern/vfs_vopops.c:257
#16 0xc0337918 in vn_close (vp=0xd64ab768, flags=2)
at /home/hasso/dragonfly-src/sys/kern/vfs_vnops.c:415
#17 0xc0337950 in vn_closefile (fp=0xc96eec70)
at /home/hasso/dragonfly-src/sys/kern/vfs_vnops.c:1109
#18 0xc02cb467 in fdrop (fp=0xc96eec70)
at /home/hasso/dragonfly-src/sys/sys/file2.h:120
#19 0xc02cb775 in closef (fp=0xc96eec70, p=0xca695d98)
at /home/hasso/dragonfly-src/sys/kern/kern_descrip.c:2221
#20 0xc02cbb13 in fdfree (p=0xca695d98)
at /home/hasso/dragonfly-src/sys/kern/kern_descrip.c:1885
#21 0xc02d1b8a in exit1 (rv=9)
at /home/hasso/dragonfly-src/sys/kern/kern_exit.c:348
#22 0xc02e29f9 in sigexit (lp=0xc17efab0, sig=9)
at /home/hasso/dragonfly-src/sys/kern/kern_sig.c:1917
#23 0xc02e4a53 in postsig (sig=9)
at /home/hasso/dragonfly-src/sys/kern/kern_sig.c:1799
#24 0xc05088ed in userret (lp=0xc17efab0, frame=<value optimized out>,
sticks=<value optimized out>)
at /home/hasso/dragonfly-src/sys/platform/pc32/i386/trap.c:289
#25 0xc0509b13 in syscall2 (frame=0xd6f4fd40)
at /home/hasso/dragonfly-src/sys/platform/pc32/i386/trap.c:1411
#26 0xc04f7076 in Xint0x80_syscall ()
at /home/hasso/dragonfly-src/sys/platform/pc32/i386/exception.s:876
#27 0x28325e7a in ?? ()

Actions #1

Updated by dillon almost 15 years ago

:Fresh build, full hammer setup and triggered by kdesu (KDE wrapper for su
:command). The panic is 100% reproduceable. Core is uploaded into leaf.
:
:...

I think I see what's going on here.  It's double-closing the
tty vnode. It looks like the case can occur if the process doing
it is in the background and all other references have gone away.
Please try this patch and tell me if it solves the problem.
-Matt

diff --git a/sys/kern/tty_tty.c b/sys/kern/tty_tty.c
index ce27467..d013009 100644
--- a/sys/kern/tty_tty.c
++ b/sys/kern/tty_tty.c
@ -147,10 +147,12 @ retry:
vdrop(ttyvp);
goto retry;
}
p->p_session->s_ttyvp = NULL;
vclrflags(ttyvp, VCTTYISOPEN);
error = VOP_CLOSE(ttyvp, FREAD|FWRITE);
vn_unlock(ttyvp);
vdrop(ttyvp);
+ vrele(ttyvp); /* ref from s_ttyvp */
} else {
error = 0;
}

Actions #2

Updated by hasso almost 15 years ago

Matthew Dillon wrote:

I think I see what's going on here. It's double-closing the
tty vnode. It looks like the case can occur if the process doing
it is in the background and all other references have gone away.

Please try this patch and tell me if it solves the problem.

It solves the problem with panic and makes kdesu actually work as well,
but it breaks other things like sh and ssh (and probably more :):

$ su
Password:
sh: can't access tty; job control turned off #

$ ssh host
ssh_askpass: exec(/usr/X11R6/bin/ssh-askpass): No such file or directory
ssh_askpass: exec(/usr/X11R6/bin/ssh-askpass): No such file or directory
ssh_askpass: exec(/usr/X11R6/bin/ssh-askpass): No such file or directory
Permission denied (publickey,keyboard-interactive).
$

Verbose output of the ssh session gives the probable point as well:

debug1: read_passphrase: can't open /dev/tty: Device not configured

Actions #3

Updated by dillon almost 15 years ago

:It solves the problem with panic and makes kdesu actually work as well,
:but it breaks other things like sh and ssh (and probably more :):

Ow.  Ok, I see what I did.  I guess I'm not supposed to 
NULL-out s_ttyvp there :-)
I'll just use a ref instead so the vrele inside the VOP_CLOSE
doesn't trigger the reclaim. The original use of vhold/vdrop was
because the reference count was being used to figure out when to
disassociate the tty. I fixed the use of v_opencount and the code
uses that now, so we should be able to safely use vref/vrele instead
of vhold/vdrop.
I'm going to hold off the release by one day and get this committed,
please test it today and Monday.
-Matt

diff --git a/sys/kern/tty_tty.c b/sys/kern/tty_tty.c
index ce27467..9b73517 100644
--- a/sys/kern/tty_tty.c
+++ b/sys/kern/tty_tty.c
@ -135,22 +135,22 @ retry:
/* * Avoid a nasty race if we block while getting the lock.
*/
- vhold(ttyvp);
+ vref(ttyvp);
error = vn_lock(ttyvp, LK_EXCLUSIVE | LK_RETRY);
if (error) {
- vdrop(ttyvp);
+ vrele(ttyvp);
goto retry;
}
if (ttyvp != cttyvp(p) || (ttyvp->v_flag & VCTTYISOPEN) == 0) {
kprintf("Warning: cttyclose: race avoided\n");
vn_unlock(ttyvp);
- vdrop(ttyvp);
+ vrele(ttyvp);
goto retry;
}
vclrflags(ttyvp, VCTTYISOPEN);
error = VOP_CLOSE(ttyvp, FREAD|FWRITE);
vn_unlock(ttyvp);
- vdrop(ttyvp);
+ vrele(ttyvp);
} else {
error = 0;
}

Actions #4

Updated by hasso almost 15 years ago

Matthew Dillon wrote:

I'm going to hold off the release by one day and get this
committed, please test it today and Monday.

Passes my brief testing at least - kdesu doesn't trigger a panic any more
and both sh and ssh are working.

Actions #5

Updated by hasso almost 15 years ago

Commited as 8e73fd395b8234b4a74562a1b84a8d9574ce6e3f.

Actions

Also available in: Atom PDF