[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 6 Jul 2020 18:22:02 -0400
From: Rich Felker <dalias@...c.org>
To: Hydro Flask <hydroflask@...mail.com>
Cc: musl@...ts.openwall.com
Subject: Re: Potential deadlock in pthread_kill()
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.
Indeed. It'd also work to disable async cancellation for the duration
of the pthread_cancel call, but that's almost surely more work.
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.
Rich
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.
