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
