Re: Spurious/undocumented EINTR from io_uring_enter

[Jens Axboe <axboe@kernel.dk>]

On 4/8/20 9:41 AM, Joseph Christopher Sible wrote:
> On 4/7/20 5:42 PM, Jens Axboe wrote:
>> Lots of system calls return -EINTR if interrupted by a signal, don't
>> think there's anything worth fixing there. For the wait part, the
>> application may want to handle the signal before we can wait again.
>> We can't go to sleep with a pending signal.
> 
> This seems to be an unambiguous bug, at least according to the BUGS
> section of the ptrace man page. The behavior of epoll_wait is explicitly
> called out as being buggy/wrong, and we're emulating its behavior. As
> for the application wanting to handle the signal, in those cases, it
> would choose to install a signal handler, in which case I absolutely
> agree that returning -EINTR is the right thing to do. I'm only talking
> about the case where the application didn't choose to install a signal
> handler (and the signal would have been completely invisible to the
> process had it not been being traced).

So what do you suggest? The only recurse the kernel has is to flush
signals, which would just delete the signal completely. It's a wait
operation, and you cannot wait with signals pending. The only
wait to retry is to return the number of events we already got, or
-EINTR if we got none, and return to userspace. That'll ensure the
signal gets handled, and the app must then call wait again if it
wants to wait for more.

There's no "emulating behavior" here, you make it sound like we're
trying to be bug compatible with some random other system call.
That's not the case at all.

-- 
Jens Axboe