If a request is finalized in the first call to the ngx_http_upstream_process_upgraded() function, e.g., because upstream server closed the connection for some reason, in the second call the u->peer.connection pointer will be null, resulting in segmentation fault. Fix is to avoid second direct call, and post event instead. This ensures that ngx_http_upstream_process_upgraded() won't be called again if a request is finalized.
Backed out 05a56ebb084a, as it turns out that kernel can return connections without any delay if syncookies are used. This basically means we can't assume anything about connections returned with deferred accept set. To solve original problem the 05a56ebb084a tried to solve, i.e. to don't wait longer than needed if a connection was accepted after deferred accept timeout, this patch changes a timeout set with setsockopt(TCP_DEFER_ACCEPT) to 1 second, unconditionally. This is believed to be enough for speed improvements, and doesn't imply major changes to timeouts used. Note that before 2.6.32 connections were dropped after a timeout. Though it is believed that 1s is still appropriate for kernels before 2.6.32, as previously tcp_synack_retries controlled the actual timeout and 1s results in more than 1 minute actual timeout by default.
Read event on a client connection might have been disabled during previous processing, and we at least need to handle events. Calling ngx_http_upstream_process_upgraded() is a simpliest way to do it. Notably this change is needed for select, poll and /dev/poll event methods. Previous version of this patch was posted here: http://mailman.nginx.org/pipermail/nginx/2014-January/041839.html
Even during execution of a request it is possible that there will be no session available, notably in case of renegotiation. As a result logging of $ssl_session_id in some cases caused NULL pointer dereference after revision 97e3769637a7 (1.5.9). The check added returns an empty string if there is no session available.