• Ilpo Järvinen's avatar
    [TCP]: tcp_simple_retransmit can cause S+L · 882bebaa
    Ilpo Järvinen authored
    This fixes Bugzilla #10384
    
    tcp_simple_retransmit does L increment without any checking
    whatsoever for overflowing S+L when Reno is in use.
    
    The simplest scenario I can currently think of is rather
    complex in practice (there might be some more straightforward
    cases though). Ie., if mss is reduced during mtu probing, it
    may end up marking everything lost and if some duplicate ACKs
    arrived prior to that sacked_out will be non-zero as well,
    leading to S+L > packets_out, tcp_clean_rtx_queue on the next
    cumulative ACK or tcp_fastretrans_alert on the next duplicate
    ACK will fix the S counter.
    
    More straightforward (but questionable) solution would be to
    just call tcp_reset_reno_sack() in tcp_simple_retransmit but
    it would negatively impact the probe's retransmission, ie.,
    the retransmissions would not occur if some duplicate ACKs
    had arrived.
    
    So I had to add reno sacked_out reseting to CA_Loss state
    when the first cumulative ACK arrives (this stale sacked_out
    might actually be the explanation for the reports of left_out
    overflows in kernel prior to 2.6.23 and S+L overflow reports
    of 2.6.24). However, this alone won't be enough to fix kernel
    before 2.6.24 because it is building on top of the commit
    1b6d427b ([TCP]: Reduce sacked_out with reno when purging
    write_queue) to keep the sacked_out from overflowing.
    Signed-off-by: default avatarIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
    Reported-by: default avatarAlessandro Suardi <alessandro.suardi@gmail.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    882bebaa
tcp_input.c 153 KB