Re: Postmaster self-deadlock due to PLT linkage resolution

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Postmaster self-deadlock due to PLT linkage resolution
Дата
Msg-id 20220830171720.iai6jwwo756z7ivw@awork3.anarazel.de
обсуждение исходный текст
Ответ на Postmaster self-deadlock due to PLT linkage resolution  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Postmaster self-deadlock due to PLT linkage resolution  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2022-08-29 15:43:55 -0400, Tom Lane wrote:
> Buildfarm member mamba (NetBSD-current on prairiedog's former hardware)
> has failed repeatedly since I set it up.  I have now run the cause of
> that to ground [1], and here's what's happening: if the postmaster
> receives a signal just before it first waits at the select() in
> ServerLoop, it can self-deadlock.  During the postmaster's first use of
> select(), the dynamic loader needs to resolve the PLT branch table entry
> that the core executable uses to reach select() in libc.so, and it locks
> the loader's internal data structures while doing that.  If we enter
> a signal handler while the lock is held, and the handler needs to do
> anything that also requires the lock, the postmaster is frozen.

Ick.


> 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?

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).

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: vignesh C
Дата:
Сообщение: Re: Handle infinite recursion in logical replication setup
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Postmaster self-deadlock due to PLT linkage resolution