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: Thu, 25 Aug 2022 22:37:03 -0400

 Taylor R Campbell <riastradh%NetBSD.org@localhost> writes:
 > Can you try the attached patch series?  Do you have a quick reproducer
 > for the problem?  Ideally we could make an automatic test for this if
 > there's a cheap reproducer to trigger the race.
 
 I've built the system with that patch added, and will start using it
 tomorrow.  I do not have a reliable reproducer, and on reflection it's
 hard to see how to make one -- unless you know of an operation that
 would hold the rtld lock for a decently long period of time.  However,
 I'm finding that my macppc Postgres buildfarm instance [1] is hitting
 this in perhaps one out of five or ten runs, so if it can survive for
 a week or two then I'll feel pretty confident that this patch fixes
 it for me.
 
 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.  PLT
 resolution is pretty much the only dynamic-loader operation that
 I can foresee happening with signals enabled in the Postgres
 postmaster --- indeed, before I saw this failure I'd have sworn
 up and down that we do *nothing* interesting with signals enabled.
 That select(2) call and the adjacent sigprocmask calls are the
 entire extent of the window for trouble.
 
 I have no opinion about the first patch -- Postgres doesn't use
 pthread_atfork.
 
 I'll report back in a week or two.
 
 			regards, tom lane
 
 [1] https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=mamba&br=HEAD