[paramiko] [MERGE] Fix obscure deadlock that can occur during re-keying

[Dwayne Litzenberger]

Robey,

I've attached a patch does the following:

- Fix deadlock: Paramiko sometimes deadlocks if the user tries to send data
  immediately after paramiko has initiated a key exchange (re-keying), but
  before the remote MSG_KEXINIT has been received.  The deadlock occurs when 
  certain messages are received (e.g. MSG_CHANNEL_WINDOW_ADJUST) that were
  in-transit when the initial MSG_KEXINIT was sent.

- Add a test case for the deadlock

- Fix __dump_packets support for SFTPServer and SFTPClient.  (Needed to make 
test.py work when Packetizer.__dump_packets = True.

<shameless-plug>
This patch took about 38 hours to produce, and was funded entirely by my 
employer, Open Systems Canada Limited.  They also paid for a lot of my work 
on the PRNG bugfixes (especially the as-yet unmerged rng*.py implementation). 
Basically, everything that came from my oscl.ca email address has been paid 
for by them.  It would be nice if they got some credit somewhere...  They're 
a small, FOSS-friendly IT services firm that could use the brand exposure.
</shameless-plug>

Cheers,
 - Dwayne

On April 15, 2008 04:58:05 pm Dwayne Litzenberger wrote:
> On April 15, 2008 01:03:00 pm Dwayne Litzenberger wrote:
> > In the main thread:
> >
> > Channel.send acquires Channel.lock, calls Channel._wait_for_send_window,
> > then calls Transport._send_user_message with a MSG_CHANNEL_DATA message.
> > Transport._send_user_message then waits for Transport.clear_to_send to be
> > set, but it's not set for some reason.  Note that Channel.lock is still
> > held by the main thread.
> >
> > Meanwhile, the Transport thread tries to process a MSG_WINDOW_ADJUST
> > message. It calls Channel._window_adjust, but that can't proceed until
> > Channel.lock is released.
>
> clear_to_send is unset (correctly) because we've just sent MSG_KEXINIT. 
> The problem seems to be that Channel.send() is holding Channel.lock, thus
> preventing still-in-transit messages like MSG_WINDOW_ADJUST from being
> processed by the Transport thread, even though we haven't received the
> remote side's MSG_KEXINIT yet.

-- 
Dwayne Litzenberger, B.A.Sc.
Information Technology Analyst

Open Systems Canada Limited
#210 - 2332 11th Ave
Regina, SK S4P0K1
Office: (306) 359-OSCL (6725)
http://www.oscl.ca/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: paramiko-deadlock-bugfix-and-testcase.bundle
Type: text/x-diff
Size: 16007 bytes
Desc: not available
Url : http://www.lag.net/pipermail/paramiko/attachments/20080418/005dc7f2/attachment.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://www.lag.net/pipermail/paramiko/attachments/20080418/005dc7f2/attachment.pgp