Re: [PATCH] net: unix: non blocking recvmsg() should not return -EINTR

[Rainer Weikusat <rweikusat@mobileactivedefense.com>]

David Laight <David.Laight@ACULAB.COM> writes:
> From: Eric Dumazet
>> From: Eric Dumazet <edumazet@google.com>
>> 
>> Some applications didn't expect recvmsg() on a non blocking socket
>> could return -EINTR. This possibility was added as a side effect
>> of commit b3ca9b02b00704 ("net: fix multithreaded signal handling in
>> unix recv routines").
>> 
>> To hit this bug, you need to be a bit unlucky, as the u->readlock
>> mutex is usually held for very small periods.
>
> The commit message for b3ca9b02b00704 looks very strange.
> Maybe something else is wrong.
>
> If we assume that u->readlock is only held for a short period
> why should it matter than the kernel decided to give the
> signal to that thread?

(This is from memory) If there's a thread blocked in recv and another
blocked on the lock and the kernel selects the thread blocked on the lock
for handling the signal, the signal won't be handled until some data is
received on the socket, ie, possibly never.