On 1/6/26 16:03, David Hildenbrand (Red Hat) wrote: > On 1/6/26 13:52, Mikulas Patocka wrote: >> >> >> On Tue, 6 Jan 2026, Michel Dänzer wrote: >> >>> On 1/5/26 19:15, Liam R. Howlett wrote: >>>> * Mikulas Patocka <[email protected]> [260104 16:17]: >>>> >>>> I'm not saying it's wrong to change the signal handling, but this is >>>> very much working around a bug in userspace constantly hammering a task >>>> with signals and then is surprised there is a response that the kernel >>>> was interrupted. >>> >>> I'd go further than that. If user space fails to retry the system call >>> in response to -EINTR, that's a user-space bug, period. It can happen >>> anytime for any number of other reasons. (That most system calls happen >>> to get away without it most of the time doesn't make it not a bug) >> >> So, I tried this - just for fun - and the machine doesn't even boot. I get >> a lot of errors about inability to open particular files on the console. >> >> Userspace is buggy, according to your definition, regardless of whether >> you like it or not. >> >> Mikulas >> >> --- >> fs/open.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> Index: linux-2.6/fs/open.c >> =================================================================== >> --- linux-2.6.orig/fs/open.c 2025-12-31 20:10:31.000000000 +0100 >> +++ linux-2.6/fs/open.c 2026-01-06 13:28:01.000000000 +0100 >> @@ -1419,6 +1419,9 @@ static int do_sys_openat2(int dfd, const >> struct filename *tmp __free(putname) = NULL; >> int err; >> >> + if (current->pid != 1 && !(get_random_u8() & 0x1)) >> + return -EINTR; > > Reading the man [1] page user space is only to expect EINTR in case it is > prepared to deal with signals (install signal handlers), no? > > There are some exception documented: > > On Linux, even in the absence of signal handlers, certain blocking > interfaces can fail with the error EINTR after the process is > stopped by one of the stop signals and then resumed via SIGCONT. > This behavior is not sanctioned by POSIX.1, and doesn't occur on > other systems. > > The Linux interfaces that display this behavior are: > > • "Input" socket interfaces, when a timeout (SO_RCVTIMEO) has > been set on the socket using setsockopt(2): accept(2), recv(2), > recvfrom(2), recvmmsg(2) (also with a non-NULL timeout > argument), and recvmsg(2). > > • "Output" socket interfaces, when a timeout (SO_RCVTIMEO) has > been set on the socket using setsockopt(2): connect(2), > send(2), sendto(2), and sendmsg(2), if a send timeout > (SO_SNDTIMEO) has been set. > > • epoll_wait(2), epoll_pwait(2). > > • semop(2), semtimedop(2). > > • sigtimedwait(2), sigwaitinfo(2). > > • Linux 3.7 and earlier: read(2) from an inotify(7) file > descriptor > > • Linux 2.6.21 and earlier: futex(2) FUTEX_WAIT, > sem_timedwait(3), sem_wait(3). > > • Linux 2.6.8 and earlier: msgrcv(2), msgsnd(2). > > • Linux 2.4 and earlier: nanosleep(2). > > > So I would expect that your test code hear breaks user space.
Since the patch is dead now, are we going to update this section in the manpage? > > [1] https://man7.org/linux/man-pages/man7/signal.7.html >
