netdev - Re: Re : Oops preceded by WARNING: at net/ipv4/tcp_input.c:1571 tcp_remove_reno

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0711151000570.7798@kivilampi-30.cs.helsinki.fi>
Date:	Thu, 15 Nov 2007 10:11:26 +0200 (EET)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	David Miller <davem@...emloft.net>
cc:	guichaz@...oo.fr, Netdev <netdev@...r.kernel.org>
Subject: Re: Re : Oops preceded by WARNING: at net/ipv4/tcp_input.c:1571
 tcp_remove_reno_sacks()

On Wed, 14 Nov 2007, David Miller wrote:

> From: "Ilpo_Järvinen" <ilpo.jarvinen@...sinki.fi>
> 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 <guichaz@...oo.fr>.
> > 
> > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
> 
> 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.