[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 Jun 2020 22:28:50 +0300
From: Dmitry Samersoff <dms@...ersoff.net>
To: musl@...ts.openwall.com, Hydro Flask <hydroflask@...mail.com>
Cc: Markus Wichmann <nullplan@....net>
Subject: Re: Potential deadlock in pthread_kill()
Hello all,
Does it make sense to trylock and immediately return ESRCH if
pthread_kill is already in progress?
-Dmitry
On 30.06.2020 19:28, Hydro Flask wrote:
> On 2020-06-30 07:58, Markus Wichmann wrote:
>> On Tue, Jun 30, 2020 at 05:26:46AM -0400, Rich Felker wrote:
>>> On Mon, Jun 29, 2020 at 11:19:39PM -0700, Hydro Flask wrote:
>>> >
>>> > Just to be clear, this doesn't only occur when calling
>>> > pthread_kill() and using pthread_self() as the target, it can be any
>>> > target thread, as long as it's the same target thread is used in the
>>> > signal handler and in the synchronous context.
>>>
>>> How so? If the target is different, the rest of the pthread_kill,
>>> including the unlock, will proceed concurrently with the signal
>>> handler. However you may be able to construct mutual-signaling
>>> deadlock cases.
>>>
>>
>> Thread A calls pthread_kill(thread_c, ...). Thread B calls
>> (concurrently) pthread_kill(thread_a, ...). Thread B's signal arrives
>> while thread A holds the killlock. Signal handler calls
>> pthread_kill(thread_c, ...).
>
> You can trigger it much more simply than that. Doesn't require multiple
> threads:
>
> 1. pthread_kill(th)
> 2. LOCK(killlock)
> 3. <signal arrives after lock>
> 4. signal handler: pthread_kill(th)
> 5. signal handler: LOCK(killlock)
>
> In the preceding example "th" can be any pthread_t value, the only
> requirement is that it's the same pthread_t in both the synchronous and
> signal handler context.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
