epoll does not report EPOLLERR events

[RalfJung]

According to the man page, epoll will always report EPOLLERR events. However, our implementation never reports them. This is a problem as Miri will silently accept the program but run it in an incorrect way. There's no good way to throw a "not supported" error here, so we should implement this event notification.

Cc @tiif

[tiif]

Right now I still haven't understood how to trigger EPOLLERR yet. I will look into this.

This is the description from the man page:

 EPOLLERR
              Error condition happened on the associated file
              descriptor.  This event is also reported for the write end
              of a pipe when the read end has been closed.

              epoll_wait will always report for this event; it is not
              necessary to set it in events when calling epoll_ctl().

It is still unclear to me what will be considered an error condition for socketpair or eventfd.

@rustbot claim

[RalfJung]

It is still unclear to me what will be considered an error condition for socketpair or eventfd.

It seems very plausible that the answer is "nothing". I would have thought closing the FD or the peer FD might do that but that doesn't seem to be the case, right? Those cases are both covered already by existing tests?

In that case I would say the fix is to add the flag to our EpollReadyEvents type, and do the plumbing that would forward such events to userspace. Then we are ready for if/when we have an FD type that emits them.

[tiif]

Actually right now I discovered a test case can trigger EPOLLER, #3820 contains the test case.

But I suspect there should be other test cases that I don't know yet. Would it makes sense to leave this issue up first, wait for bug reports, and fix later?

This bug will be discoverable if the user managed to write a test where our epoll notification differs from real system.

[RalfJung]

Actually right now I discovered a test case can trigger EPOLLER, #3820 contains the test case.

Good catch!

If we know about a case, IMO we should implement it.