Re: bin/60275: sh(1): race condition in signal handling on background subshell fork

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

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

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Christos Zoulas <christos%zoulas.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: bin/60275: sh(1): race condition in signal handling on background subshell fork
Date: Wed, 20 May 2026 03:31:39 +0700

     Date:        Tue, 19 May 2026 14:30:10 -0400
     From:        Christos Zoulas <christos%zoulas.com@localhost>
     Message-ID:  <645CF0B9-1ADB-4DFC-B5BC-E9844896BC1F%zoulas.com@localhost>
 
 
   | vfork() is temperamental.
 
 Yes, I know.   Perhaps fortunately, at the minute, our shell doesn't
 even really pretend to build outside NetBSD, so some of the issues aren't
 relevant (something on my list to perhaps work on, if I ever find the time).
 
   | In some implementations the signal disposition is shared
   | between parent and the vforked() child.
 
 Which is what I am dealing with at the minute ... if that isn't true of
 NetBSD, then I have been (today) wasting some time - as I said, I can't
 think of a good way to test this new issue (vfork() only problem).
 
 What would help all of this, the issue Taylor found, and this variant
 related problem, would be if sigaction() had a SA_RESETFORK flag, to
 cause the signal in question to be reset to the default (SIG_DFL) in the
 child after a fork() (including vfork()).   Want to add that?   All these
 issues could be made to simply vanish if that existed.
 
 kre