|
Message-ID: <275470aa6820d420339929a1fe409d89@yqxmail.com> Date: Tue, 30 Jun 2020 09:28:44 -0700 From: Hydro Flask <hydroflask@...mail.com> To: musl@...ts.openwall.com Cc: Markus Wichmann <nullplan@....net> Subject: Re: Potential deadlock in pthread_kill() 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.