[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5144617df2c8010b62813b5ed2c0dfef@yqxmail.com>
Date: Mon, 06 Jul 2020 15:37:47 -0700
From: Hydro Flask <hydroflask@...mail.com>
To: musl@...ts.openwall.com
Subject: Re: Potential deadlock in pthread_kill()
On 2020-07-06 15:22, Rich Felker wrote:
> On Mon, Jul 06, 2020 at 03:14:43PM -0700, Hydro Flask wrote:
>> On 2020-07-06 15:00, Rich Felker wrote:
>> >Yes, I see it clearly now. Sorry it took a while. I have prepared the
>> >attached patch which I'll push soon if there are no problems.
>>
>> Needs one more tiny tweak. I noticed that pthread_cancel() calls
>> pthread_kill(). That means pthread_kill() must be async-cancel-safe.
>> If an asynchronous cancellation happens after pthread_kill() grabs
>> the killlock, then it will deadlock because the asynchronous
>> pthread_exit(PTHREAD_CANCELED) call will then recursively try to
>> grab killlock.
>>
>> The solution as far as I can tell is to not just block app signals
>> when grabbing killlock, but all signals.
>
> Are you in agreement that it suffices for only pthread_kill to block
> all signals? (Still blocking just app signals everywhere else) The
> scheduling functions could be changed too, but I'm hesitant to change
> pthread_exit without thinking about it further since it has a lot more
> subtleties. And I think only pthread_kill needs it since it's the only
> one that needs to be AC-safe.
Yes I think that's right, since every other function that grabs the
killlock can assume that async cancellation won't happen.
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.
