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.
[1] https://man7.org/linux/man-pages/man7/signal.7.html
--
Cheers
David
