|
Message-ID: <20200706222202.GN6430@brightrain.aerifal.cx> 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.