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: Taylor R Campbell <riastradh%NetBSD.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost
Subject: Re: kern/56979: fork(2) fails to be signal safe
Date: Fri, 26 Aug 2022 09:23:54 -0400

 Taylor R Campbell <riastradh%NetBSD.org@localhost> writes:
 > From: Tom Lane <tgl%sss.pgh.pa.us@localhost>
 >> FWIW, the second patch certainly looks like it will alleviate the
 >> symptom I'm seeing.  I suppose it would not fix cases where the
 >> signal interrupts an operation holding the rtld lock exclusively;
 >> but I do not think that will be a problem for my use-case.
 
 > The rtld exclusive lock blocks signals (except for SIGTRAP, which
 > might be a bug...).
 
 D'oh, I knew that, having looked at the code a few weeks ago...
 but yeah, I find the SIGTRAP exception troubling.
 
 On the whole, the notion that something as simple as a C function call
 can result in behind-your-back taking of a lock is pretty scary.
 Maybe it's only of concern to code directly associated with the
 dynamic loader, but I'm not very convinced.
 
 			regards, tom lane