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.