Subject: Re: kern/37603: ctrl-z handling problem: processes afterwards also stopped
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: Christos Zoulas <christos@zoulas.com>
List: netbsd-bugs
Date: 12/23/2007 20:45:02
The following reply was made to PR kern/37603; it has been noted by GNATS.

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, kern-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: kern/37603: ctrl-z handling problem: processes afterwards also stopped
Date: Sun, 23 Dec 2007 15:44:25 -0500

 On Dec 23,  7:55pm, wiz@NetBSD.org (Thomas Klausner) wrote:
 -- Subject: kern/37603: ctrl-z handling problem: processes afterwards also st
 
 | >Number:         37603
 | >Category:       kern
 | >Synopsis:       ctrl-z handling problem: processes afterwards also stopped
 | >Confidential:   no
 | >Severity:       serious
 | >Priority:       medium
 | >Responsible:    kern-bug-people
 | >State:          open
 | >Class:          sw-bug
 | >Submitter-Id:   net
 | >Arrival-Date:   Sun Dec 23 19:55:01 +0000 2007
 | >Originator:     Thomas Klausner
 | >Release:        NetBSD 4.99.42/amd64; also on NetBSD 4.99.44/i386 (gson@gson.org)
 | >Organization:
 | >Environment:
 | System: NetBSD hiro 4.99.42 NetBSD 4.99.42 (HIRO64) #5: Wed Dec 19 09:28:31 CET 2007 wiz@hiro:/usr/obj/src.amd64/sys/arch/amd64/compile/HIRO64 amd64
 | Architecture: x86_64
 | Machine: amd64
 | >Description:
 | When I stop an emacs21 process on the console, all processes started
 | later in the same shell (while emacs is suspended) also immediately seem
 | to get a stop signal.
 | 
 | >How-To-Repeat:
 | E.g. boot single user, shell=/bin/ksh
 | export TERM=vt100
 | emacs -nw a <ctrl-z>
 | man man
 | 
 | The man process will suspend itself after about half a second -- it's
 | not immediate, but very quick.
 | Putting it in the foreground again doesn't help -- the behaviour
 | repeats (man is suspended again immediately).
 | 
 | Looks like the stop signal sending is stuck :)
 
 This broke in tty.c 1.200 -> 1.201. The deferred tty signal code seems to be
 broken. This makes things better, but there is still a problem with the
 suspended process receiving an extra TTOUT.
 
 Index: tty.c
 ===================================================================
 RCS file: /cvsroot/src/sys/kern/tty.c,v
 retrieving revision 1.208
 diff -u -u -r1.208 tty.c
 --- tty.c	8 Dec 2007 19:29:49 -0000	1.208
 +++ tty.c	23 Dec 2007 20:41:08 -0000
 @@ -843,8 +843,10 @@
  		while (isbackground(curproc, tp) &&
  		    p->p_pgrp->pg_jobc && (p->p_sflag & PS_PPWAIT) == 0 &&
  		    !sigismasked(l, SIGTTOU)) {
 +			mutex_enter(&proclist_mutex);
 +			pgsignal(p->p_pgrp, SIGTTOU, 1);
 +			mutex_exit(&proclist_mutex);
  			mutex_spin_enter(&tty_lock);
 -			ttysig(tp, TTYSIG_PG1, SIGTTOU);
  			error = ttysleep(tp, &lbolt, true, 0);
  			mutex_spin_exit(&tty_lock);
  			if (error) {
 @@ -1631,7 +1633,9 @@
  			mutex_spin_exit(&tty_lock);
  			return (EIO);
  		}
 -		ttysig(tp, TTYSIG_PG1, SIGTTIN);
 +		mutex_enter(&proclist_mutex);
 +		pgsignal(p->p_pgrp, SIGTTIN, 1);
 +		mutex_exit(&proclist_mutex);
  		error = ttysleep(tp, &lbolt, true, 0);
  		mutex_spin_exit(&tty_lock);
  		if (error)
 @@ -1896,8 +1900,10 @@
  			error = EIO;
  			goto out;
  		}
 +		mutex_enter(&proclist_mutex);
 +		pgsignal(p->p_pgrp, SIGTTOU, 1);
 +		mutex_exit(&proclist_mutex);
  		mutex_spin_enter(&tty_lock);
 -		ttysig(tp, TTYSIG_PG1, SIGTTOU);
  		error = ttysleep(tp, &lbolt, true, 0);
  		mutex_spin_exit(&tty_lock);
  		if (error)