linux-kernel - Re: recv() hangs until SIGCHLD ?

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]

Message-ID: <20081012084701.21275a3a@extreme>
Date:	Sun, 12 Oct 2008 08:47:01 -0700
From:	Stephen Hemminger <shemminger@...tta.com>
To:	davids@...master.com
Cc:	<linux-net@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: recv() hangs until SIGCHLD ?

On Sat, 11 Oct 2008 05:20:37 -0700
"David Schwartz" <davids@...master.com> wrote:

> 
> Nicolas Cannasse wrote:
> 
> > The sockets are non-blocking.
> 
> Ouch, that's a serious bug. Non-blocking operations shouldn't block!
> 
> > Checking with netstat and ss I can confirm that both Send and Recv
> > queues are empty, which makes the recv() behavior consistent.
> >
> > However since this problem does not occur without threads, we can be
> > sure that the blame is still on the receiver.
> >
> > In a practical case, we have a thread blocked in recv() for more than 12
> > hours, which is way beyond the timeout of the sender connection. The
> > socket has already been closed by the sender so recv() should at least
> > be noticed and returns 0.
> 
> Can you clarify what you mean by "the socket has already been closed by the
> sender"? You mean the other end of the TCP connection shut it down? By "the
> socket", you don't mean the socket you called 'recv' on, right? You mean the
> socket on the other end that's connected to it?
> 
> > Is it safe to assume that when either send() or recv() get interrupted
> > by a signal and returns EINTR, no actual data has been either sent or
> > consumed ? And if it's not, is there any other way around this ?
> 
> EINTR can only be return if 'send' or 'recv' have not sent or received
> anything. Otherwise the connection would be left in an indeterminate state.

Does application correctly handle the case where recv() returns 0?
This indicates the TCP connection is closed by the other end.
It is incorrect to assume that a return of 0 in non-blocking mode
is the same as -1. The only correct action after receiving 0 bytes
(even in non-blocking mode), is to close the socket. If you attempt
to do another receive, the result could be that the recv() waits for
another event (more data or FIN), which can never happen since socket
is closed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/