Re: sem_wait and EINTR

[Markus Wichmann <nullplan@gmx.net>]

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