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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 26 Mar 2014 19:46:05 +0000
From:	Rainer Weikusat <rweikusat@...ileactivedefense.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	David Laight <David.Laight@...LAB.COM>,
	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] net: unix: non blocking recvmsg() should not return -EINTR

Eric Dumazet <eric.dumazet@...il.com> writes:
> On Wed, 2014-03-26 at 15:13 +0000, Rainer Weikusat wrote:
>
>> (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.
>
> Look at what we do for AF_INET. We handle this the proper way.
>
> If we are 'interrupted' by a signal while sleeping in lock_sock(),
> recvmsg() on a non blocking socket, we return -EAGAIN properly, not
> -EINTR.
>
> Fact that we potentially sleep to get the socket lock is hidden for the
> user, its an implementation detail of the kernel.
>
> We never return -EINTR, as stated in manpage for non blocking sockets.

There is (to the best of my knowledge) no man page which specifically
states that "socket is non-blocking" means "receive operation can't be
interrupted by a signal before any data was received" and telling
userspace "no data is available right now" when the operation was
actually interrupted by a signal before checking is still inaccurate.
The underlying problem would seem to be that a O_NONBLOCK call might
actually block forever in case a blocking receiver sits on the lock and
no data is ever received. Hence my original suggestion that it should
use a trylock-operation. But there are presumably downsides to this as
well, I didn't really think through it.

As I already wrote, this is a theoretical problem with no really
satisfactory solution minus noting that both 'nonblocking sockets' and
'multithreaded kernels' are somewhat alien concepts when considering the
system where EINTR originated (AFAIK). Also, it doesn't really matter:
If it was commonly assumed that O_NONBLOCK would imply 'no EINTR', the
kernel should behave accordingly for pragmatic reasons, not because
"commonly assumed" is the same as "obviously correct" (although it is
not uncommon for people to assume that common assumption are
must be obviously correct because they're common assumptions :-).

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html