Deadlock bug in ssl library

[Johan Bevemyr]

The deadlock occurs when the client sends lots of data to an 
erlang SSL server and the SSL server queries the SSL library
for for example ssl:peername().

What happens is that the esock port program will try to write
the data to the ssl_broker, and eventually block in write() and
stay blocked until erlang has read the data.

However, suppose you have the following situation.

1. A process recv: some data from the SSL socket and then proceeds
   without reading all data.

2. The esock port program blocks since it tries to write (it will not
   block right way since there are both read and write buffers on the
   TCP level on the socket between the ssl_broker and esock.

3. The same process as in 1 tries to read the peername from the SSL
   socket. This will cause the broker to send an GETPEERNAME request
   via the ssl_server to esock, and wait for the reply. Howerver
   esock cannot answer since it blocks in write() of the SSL data.

All SSL traffic is blocked at this point and no further SSL processing
can take place.

The solution is to make the (proxy) socket between esock and the
ssl_broker non-blocking (which appears to be the intention).

Patch against r10-b4 lib/ssl/c_src/esock.c:

452a453
>                       SET_NONBLOCKING(proxysock);
988,990c989,991
<                   } else if (cc == 0) {
<                       /* EOF proxy */
<                       DEBUGF(("proxy eof\n"));
---
>                   } else {
>                       /* EOF proxy or error */
>                       DEBUGF(("proxy eof or error\n"));
1000,1003d1000
<                   } else {
<                       /* This should not happen */
<                       DEBUGF(("ERROR: proxy readmask set, cc < 0, fd = %d"
<                              " proxyfd = %d\n", cp->fd, cp->proxy->fd));


/Johan and Martin