DragonFlyBSD

: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;
}

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

: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;
}

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.

Commited as 8e73fd395b8234b4a74562a1b84a8d9574ce6e3f.