Re: kern/56979: fork(2) fails to be signal safe

[Tom Lane <tgl%sss.pgh.pa.us@localhost>]

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

From: Tom Lane <tgl%sss.pgh.pa.us@localhost>
To: Robert Elz <kre%munnari.OZ.AU@localhost>
Cc: lib-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, gnats-bugs%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/56979: fork(2) fails to be signal safe
Date: Sat, 15 Oct 2022 22:46:52 -0400

 Robert Elz <kre%munnari.OZ.AU@localhost> writes:
 >    |  Well, it *was* a signal handler, but once it issues fork() I wouldn't
 >    |  personally regard it as a signal handler anymore.
  
 >  Sorry, but that is utter nonsense.
 
 Well, here is the actual problem: with this implementation, the mere
 act of invoking a C function is not guaranteed to be async-signal-safe,
 depending on whether it crosses a not-terribly-well-defined linkage
 boundary.
 
 POSIX forgot to specify that that's not okay, because who would think
 you need to mention it?  They certainly aren't going to write down
 that addition is async-signal-safe, for example; but there's nothing
 in either POSIX or the C standard that distinguishes some bare-C
 operations from others.  Indeed, depending on platform and data type
 involved, I wouldn't be too surprised if addition is sometimes *not*
 async-signal-safe on NetBSD 10.  Which nominally-primitive C operations
 get implemented by calls to libgcc_s.so?
 
 I also suspect that it's possible to construct examples that violate the
 explicit letter of the POSIX spec, in that they list a bunch of functions
 that are required to be async-signal-safe but are in libc.so and therefore
 require RTLD resolution before the first call.  Consider, say, select()
 in the mainline, and while we're resolving that we get an interrupt and
 the signal handler tries to invoke lseek() and that requires resolution.
 I'm failing to see how the resulting deadlock is allowed per POSIX.
 
 Anyway, linking with "-z now" solves this problem sufficiently for my
 purposes.
 
 			regards, tom lane