tree 20cd82885105f09c7ddef2eafd5739dcdba46a46
parent 4c747b82ab7c91ebd5bff3cde22aafae2077e58c
author Matt Rosencrantz <mattr@google.com> 1429296658 -0700
committer Matt Rosencrantz <mattr@google.com> 1429296659 -0700

rpc/stream/vc: Fix a race in the VC code that sometimes prevents TLS
from properly negotiating.

This race was caused by CL 9932.  It used to be that we set
vc.acceptHandshakeDone at the same time we set vc.handshakeFID (we did
both under a mutex).  This prevented a race where we first accept the
connection, but then before we set vc.handshakeFID we get a packet
and during DispatchPayload we'd call vc.waitForHandshakeLocked which
deadlocks.

In the new code we need to set vc.acceptHandshakeDone in cases where
we aren't creating the handshakeConn at all, so these two lines of
code got separated, causing the race described above.

This change fixes the race by not relying on setting vc.handshakeFID.
In fact the variable is eliminated.  Instead the server requires incomming
handshake and auth connections to have the expected FIDs and returns
errors if they don't (instead of assuming that the first accepted fid
is the handshake fid).

Now we correctly bypass the waitForHandshakeLocked call.

Change-Id: I2db3977827f8d93e17e57c09294c53787a89073e