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.