Bug 582722

Created attachment 406848 [details]
Backported patch from 2.6.32 that fixes the TCP premature timeout issue

Description of problem:

A TCP session streaming data out of a machine with both FRTO and TSO enabled can prematurely timeout under some conditions, and it does this without sending any packets with FIN or RST.  This causes the socket to disappear on the sender side, but the receiver is still in established state and sits there forever (or until it tries to send something on the connection and gets an error).

Version-Release number of selected component (if applicable):

This has been observed in the 5.1 kernel (2.6.18-53) and 5.4 kernel (2.6.18-164)

How reproducible:

Very reproducible

Steps to Reproduce:
1. Get 2 machines - machine A is under test, it must have an ethernet device that supports TSO.  Machine B will receive data from machine A.
1. Enable FRTO on machine A by doing 'echo 1 > /proc/sys/net/ipv4/tcp_frto'
2. Enable TSO on outbound interface of machine A by doing 'ethtool -K <devname> tso on'.  Verify it is on with 'ethtool -k <devname>'.
3. On machine B, initiate a transfer of a large file from machine A using scp or ftp (I tested with scp, though I think any one-way TCP transfer will work)
4. Induce a small packet loss.  For example, do this on machine B: 'iptables -A INPUT -s <machine A's IP> -j DROP; iptables -D INPUT -s <machine A's IP> -j DROP'
  
Actual results:

After 15 retransmissions, the transmitting machine abruptly closes the socket (IE sets the state of the TCP socket internally to CLOSED) without sending any packet with a FIN or RST to the other side.  From a user point of view, the socket will be gone on machine A, but machine B will still have a socket in the 'ESTABLISHED' state.

Expected results:

TCP should recover from a small packet loss and continue the transfer with minimal interruption.

Additional info:

I don't understand the entire mechanism, but through adding some debug messages I have established that the test at the end of tcp_write_timeout() in net/ipv4/tcp_timer.c becomes true and it calls tcp_write_err() which forcibly shuts down the socket.  Turning off FRTO or TSO eliminates the problem.

I backported a change from 2.6.32 that fixes the issue in my testing.  This patch changes the test in tcp_write_timeout() and a couple other places to be based on how long this socket has been retransmitting instead of the number of retransmits.  The original code is at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6fa12c85031485dff38ce550c24f10da23b0adaa (though I also grabbed some updates to the retransmits_timed_out() function).  A patch is attached.