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; + err = build_open_flags(how, &op); if (unlikely(err)) return err;
