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

[Vlastimil Babka <vbabka@suse.cz>]

On 1/6/26 12:36, 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)
> 
> (This is assuming the system call can be safely retried, otherwise
> returning -EINTR to user space for non-fatal signals would be a kernel
> bug)

This is true and the userspace should be fixed. But the kernel still tries
hard to support even broken userspace.
Even though commit 7906d00cd1f6 is very old now, from 2.6.27, we could say
that technically it violated the "do not break userspace" rule.
It's not always easy to undo such breakages, especially after many years,
and if some other userspace meanwhile starts depending on the new behavior.
But I doubt that's the case here and anything will have issues with
non-fatal signals being delayed.

>>> I'm submitting this patch for the stable kernels, because this bug may
>>> cause random failures in any code that calls mm_take_all_locks.
>> 
>> They aren't random failures, they are a response to a signal sent to the
>> process that may be taking a very long time to do something.
>> 
>> I really don't see how continuously sending signals at a short interval
>> interrupting system calls can be considered random failures, especially
>> when the return is -EINTR which literally means "Interrupted system
>> call".  How else would you interrupt a system call, if not a signal?
>> 
>> I feel like we are making the code less versatile to work around the
>> fact that userspace didn't realise that system calls could be
>> interrupted without a fatal signal.
>> 
>> And from that view, I consider this a functional change and not a bug
>> fix.
> 
> I agree.
> 
>