On Wed, 14 Nov 2007, David Miller wrote: > From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> > Date: Wed, 14 Nov 2007 15:32:58 +0200 (EET) > > > [PATCH] [TCP] FRTO: Clear frto_highmark only after process_frto that uses it > > > > I broke this in commit 3de96471bd7fb76406e975ef6387abe3a0698149. > > 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 won't hurt. It may > > still be useful in some other, possibly legimate, scenario. > > > > Reported by Chazarain Guillaume <[EMAIL PROTECTED]>. > > > > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> > > Applied. > > Thanks for making such an incredibly thorough investigation > into this bug!
I suppose this bug also caused all those spurious rtos I used to see with my home connection (~10% of all RTOs during 10M scp transfer). They seemed a bit out of place because it's all wired and low RTT. Though there are bw limits enforced by ISP which I first suspected could cause it, except for suspecting bug in my code of course :-). ...It seems I can drop investigating them now since last evening test run gave 0 spurious RTOs :-). Thanks Chazarain for you report. -- i.
