From e1cd8f78f8cbfa314a095dbf704707217c8ee197 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Ilpo=20J=E4rvinen?= Date: Wed, 14 Nov 2007 15:55:09 -0800 Subject: [PATCH] [TCP] FRTO: Clear frto_highmark only after process_frto that uses it MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit I broke this in commit 3de96471bd7fb76406e975ef6387abe3a0698149: [TCP]: Wrap-safed reordering detection FRTO check tcp_process_frto should always see a valid frto_highmark. An invalid frto_highmark (zero) is very likely what ultimately caused a seqno compare in tcp_frto_enter_loss to do the wrong leading to the LOST-bit leak. Having LOST-bits integry ensured like done after commit 23aeeec365dcf8bc87fae44c533e50d0bb4f23cc: [TCP] FRTO: Plug potential LOST-bit leak won't hurt. It may still be useful in some other, possibly legimate, scenario. Reported by Chazarain Guillaume . Signed-off-by: Ilpo Järvinen Signed-off-by: David S. Miller --- Reading git-format-patch failed