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 23:03:04 -0400

 I wrote:
 > 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.
 
 Ah, sorry, I wasn't thinking very clearly there: the mainline would need
 to be doing something that takes the RTLD lock exclusively.  Not that
 there's any shortage of cases that do that.  Then, if a signal handler
 interrupts that and invokes one of the required-to-be-safe libc
 functions for the first time in the program, you have a deadlock
 in a situation that absolutely should be legal per POSIX.
 
 The Postgres case I started with does not exhibit this, because
 we don't do anything in the signals-enabled part of mainline that
 would involve an exclusive RTLD lock.  Nonetheless, taking a shared
 RTLD lock in a signal handler is clearly a hazard for POSIX compliance,
 and this system seems like it will do that in cases that POSIX requires
 to be legal.
 
 			regards, tom lane