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

["David Hildenbrand (Red Hat)" <david@kernel.org>]

On 1/7/26 10:55, Vlastimil Babka wrote:
> 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?

Yeah, I think we should better clarify the man page to whatever the 
result of this patch set (and v4 that was posted :) ) will be.

I'm afraid I won't have any capacity for that. @Mikulas?

-- 
Cheers

David