Re: Postmaster self-deadlock due to PLT linkage resolution - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Postmaster self-deadlock due to PLT linkage resolution
Date
Msg-id 3705480.1661880279@sss.pgh.pa.us
Whole thread Raw
In response to Re: Postmaster self-deadlock due to PLT linkage resolution  (Andres Freund <andres@anarazel.de>)
Responses Re: Postmaster self-deadlock due to PLT linkage resolution
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2022-08-29 15:43:55 -0400, Tom Lane wrote:
>> The attached patch seems to fix the problem, by forcing resolution of
>> the PLT link before we unblock signals.  It depends on the assumption
>> that another select() call appearing within postmaster.c will share
>> the same PLT link, which seems pretty safe.

> Hm, what stops the same problem from occuring with other functions?

These few lines are the only part of the postmaster that runs with
signals enabled and unblocked.

> Perhaps it'd be saner to default to building with -Wl,-z,now? That should fix
> the problem too, right (and if we combine it with relro, it'd be a security
> improvement to boot).

Hm.  Not sure if that works on NetBSD, but I'll check it out.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Postmaster self-deadlock due to PLT linkage resolution
Next
From: Nathan Bossart
Date:
Subject: Re: replacing role-level NOINHERIT with a grant-level option