Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 29 Jun 2020 23:19:39 -0700
From: Hydro Flask <>
Cc: Rich Felker <>
Subject: Re: Potential deadlock in pthread_kill()

>>         int pthread_kill(pthread_t t, int sig)
>>         {
>>                 int r;
>>                 LOCK(t->killlock);
>>                 r = t->tid ? -__syscall(SYS_tkill, t->tid, sig)
>>                         : (sig+0U >= _NSIG ? EINVAL : 0);
>>                 UNLOCK(t->killlock);
>>                 return r;
>>         }
>> Thank you for your attention.
> Thanks. It looks like this case was overlooked in the pthread_cancel
> fix that was commit 060ed9367337cbbd59a9e5e638a1c2f460192f25. The
> possibility of blocking signals was even mentioned there but deemed
> unnecessary.
> A simpler/lighter fix might be, before the lock,
> 	if (t==__pthread_self())
> 		return -__syscall(SYS_tkill, t->tid, sig);
> since no lock is needed if targeting self; t->tid is necessarily valid
> in that case.

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.

Looking at the commit message you references, I think the only fix for 
all cases is to block signals before taking the killlock. If there is a 
way to avoid the killlock altogether that would also fix it. Thanks 
again for confirming the issue.


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.