Re: [PATCH v3 2/3] mm: only interrupt taking all mm locks on fatal signal

[Vlastimil Babka <vbabka@suse.cz>]

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 <mpatocka@redhat.com> [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
>