Date: Thu, 6 Dec 2018 16:57:56 +0100 From: Markus Wichmann <nullplan@....net> To: musl@...ts.openwall.com Subject: Re: sem_wait and EINTR On Wed, Dec 05, 2018 at 10:17:56PM -0500, Rich Felker wrote: > I'd like it if we could avoid the pre-linux-2.6.22 bug of spurious > EINTR from SYS_futex, but I don't see any way to do so except possibly > wrapping all signal handlers and implementing restart-vs-EINTR > ourselves. So if we need to change this, it might just be a case where > we say "well, sorry, your kernel is broken" if someone is using a > broken kernel. > > Thoughts? > > Rich I really don't know what you are getting at, here. In the hypothetical case you detected an EINTR return without a signal having been handled, you could just retry the syscall. The problem is getting that information in the first place. Practically, I see a lot of work for little gain. Wrapping all signal handlers means we need to save up to _NSIG function pointers. Access to those doesn't need serialization any more than sigaction() does. Though, what does it mean if someone changes the signal handler while we are in the wrapper? Due to SA_SIGINFO we'd need two different wrappers. Or we just always set SA_SIGINFO in the kernel. I don't know if that incurs a runtime cost in the kernel, though. On the plus side, restorers would get simpler. Does the "actual signal arrived" bit need to be thread local? And what about race conditions? Well, OK, most races I can think of aren't actually a problem. Any signal arrival between resetting the flag before the syscall and checking it after the syscall would then count. So, all in all we need between 64 and 128 additional machine words in the data section, sigaction() becomes more complicated, all users of __timedwait_cp() become more complicated (you do want to make this behavior consistent, right?), signal handling becomes more complicated over all, and all of that just so that sem_wait() can fail but not under all circumstances. Speaking of calls that shouldn't fail but do: Is futex_wake() affected by the same bug? Ciao, Markus
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.