Re: kern/38670: ^Z does not work anymore for this program.

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR kern/38670; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: Christos Zoulas <christos%zoulas.com@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost,
        gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/38670: ^Z does not work anymore for this program.
Date: Sun, 22 Feb 2009 10:01:06 +0000

 On Sun, May 18, 2008 at 01:46:57PM -0400, Christos Zoulas wrote:
  > |  That seems to have come in with 4.4BSD, not sure what it's all about.
 
 This comment was lost during some of the reorganization:
 
                    /*
                     * If a child holding parent blocked, stopping could
                     * cause deadlock: discard the signal.
                     */
 
 I'm not sure what this hypothetical deadlock would be, though.
 
  > The regression has been introduced recently though. This works fine with
  > NetBSD rebar.astron.com 4.99.1 NetBSD 4.99.1 (ASTRON) #2: Fri Sep  8 
15:10:53 EDT 2006  
christos%rebar.astron.com@localhost:/usr/src/sys/arch/i386/compile/ASTRON i38
 
 What happened is that the interruptible tsleep() in the parent process
 that waits for the child to exec got changed to an uninterruptible
 cv_wait(). Thus, in your example, the parent processes of your example
 would stop, which is sufficient for the shell to report a stopped job,
 and the child calling sleep() wouldn't.
 
 Changing that call to cv_wait_sig() ought to restore the previous
 behavior; however, it's not clear that this is a particularly good
 idea, because if a signal arrives and results in ERESTARTSYS there'll
 be another child process created, and if it results in EINTR then the
 parent and the child will both be running on the same stack in the
 same address space, and demons will fly out of someone's nose.
 
 In 4.99.1 it might have worked to just stop and continue the parent,
 provided SIG_DFL for both SIGTSTP and SIGCONT, because stopped
 processes got stopped in their tracks wherever they happened to be in
 the kernel (and while holding whatever locks they happened to be
 working with, etc.) but that apparently got fixed last March; now it
 requires either EINTR or ERESTARTSYS.
 
 However, since having arbitrarily long uninterruptible waits isn't
 such a great idea, maybe we should try to come up with a way to make
 this work. Or maybe an adequate substitute is to change the WCHAN to
 "vfork" so one can at least tell what's happening and find/kill off
 the child process if things are stuck. But this probably would
 probably require breaking the CV abstraction.
 
 Also, I wonder what happens if someone does ptrace(PT_ATTACH, ...) on
 a vfork child. This should probably be forbidden; it currently isn't
 and I suspect it will make a mess.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost