[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b3650e579c2b20b6e076e5c0036f7740@yqxmail.com>
Date: Mon, 29 Jun 2020 23:19:39 -0700
From: Hydro Flask <hydroflask@...mail.com>
To: musl@...ts.openwall.com
Cc: Rich Felker <dalias@...c.org>
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.
Hydro
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.
