1. 19 Oct, 2007 2 commits
  2. 18 Oct, 2007 14 commits
  3. 12 Oct, 2007 2 commits
  4. 07 Oct, 2007 2 commits
  5. 06 Oct, 2007 17 commits
  6. 24 Sep, 2007 3 commits
    • Adrian Bunk's avatar
      Linux 2.6.16.54 · 334b8bd4
      Adrian Bunk authored
      334b8bd4
    • Adrian Bunk's avatar
      Linux 2.6.16.54-rc1 · eaf1071e
      Adrian Bunk authored
      eaf1071e
    • Ilpo Järvinen's avatar
      TCP: Fix TCP handling of SACK in bidirectional flows · 3198d0f1
      Ilpo Järvinen authored
      It's possible that new SACK blocks that should trigger new LOST
      markings arrive with new data (which previously made is_dupack
      false). In addition, I think this fixes a case where we get
      a cumulative ACK with enough SACK blocks to trigger the fast
      recovery (is_dupack would be false there too).
      
      I'm not completely pleased with this solution because readability
      of the code is somewhat questionable as 'is_dupack' in SACK case
      is no longer about dupacks only but would mean something like
      'lost_marker_work_todo' too... But because of Eifel stuff done
      in CA_Recovery, the FLAG_DATA_SACKED check cannot be placed to
      the if statement which seems attractive solution. Nevertheless,
      I didn't like adding another variable just for that either... :-)
      Signed-off-by: default avatarIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      3198d0f1