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 09:23:41 +0700

     Date:        Tue, 19 May 2026 17:16:38 -0400
     From:        Christos Zoulas <christos%zoulas.com@localhost>
     Message-ID:  <0817055A-FBA0-4939-BD0A-52ED5884B94A%zoulas.com@localhost>
 
 
   | Perhaps it is time to ditch vfork() in sh and use posix_spawn() instead.
 
 We might be able to do that for the vfork() case, perhaps, I will consider
 it as a possible enhancement, but the suggestion for SA_RESETFORK was more
 for the fork() case (Taylor's original issue), the vfork() version would
 just come along for the ride in that case.   We certainly can't replace
 the uses of fork() in sh with posix_spawn().
 
   | Otherwise the only solution is to block the relevant signals and save
   | signal handlers bebore vfork() and then restore/unblock them once the
   | child is done.
 
 That is more or less what was done to fix the fork() issue.   Fixing the
 vfork() case just needed to be a bit more careful how that was done, and
 also what's done in the signal handler, if in a vfork() child, should one
 be called.
 
 Having SA_RESETFORK as a sigaction flag would save all those extra sys calls,
 plus all the ones that the child after either fork variant needs to do to
 return all the caught signals back to SIG_DFL.
 
 kre