netdev - Re: [RFC][PATCH 1/2] TCP: fix lost retransmit detection

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.0710081258440.31129@kivilampi-30.cs.helsinki.fi>
Date:	Mon, 8 Oct 2007 14:11:55 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	TAKANO Ryousei <takano@...-inc.co.jp>
cc:	Netdev <netdev@...r.kernel.org>, y-kodama@...t.go.jp
Subject: Re: [RFC][PATCH 1/2] TCP: fix lost retransmit detection

On Sun, 7 Oct 2007, TAKANO Ryousei wrote:

> From: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
> Subject: Re: [RFC][PATCH 1/2] TCP: fix lost retransmit detection
> Date: Fri, 5 Oct 2007 13:02:07 +0300 (EEST)
> 
> > On Thu, 4 Oct 2007, TAKANO Ryousei wrote:
> > 
> > In case sacktag uses fastpath, this code won't be executed for the skb's 
> > that we would like to check (those with SACKED_RETRANS set, that are 
> > below the fastpath_skb_hint). We will eventually deal with the whole queue 
> > when fastpath_skb_hint gets set to NULL, with the next cumulative ACK that 
> > fully ACKs an skb at the latest. Maybe there's a need for a larger surgery 
> > than this to fix it. I think we need additional field to tcp_sock to avoid 
> > doing a full-walk per ACK:
>
> I think the problem occurs in slowpath. For example, in case when the receiver
> detects and sends back a new SACK block, the sender may fail to detect loss
> of a retransmitted packet.

...No, the slow path is very likely to _correct_ the problem! The problem 
occurs because fastpath _skips_ processing of skbs below fastpath_skb_hint 
whereas slowpath starts from tcp_write_queue_head. The retransmitted skbs 
we're interested in reside exactly on that skipped range.

Currently fastpath_skb_hint is cleared rather often when it would not be 
mandatory, e.g., when a cumulative ACK arrives, thus slow-path is forced 
often enough for this problem to not show up too often in any real 
scenario, yet it's broken as is and should be fixed. ...It's actually 
something which is on a way for any solution which reduces the number of 
walked skb per ACK.

> > In future, please base your work to current development tree instead of 
> > linus' tree (net-2.6.24 at this point of time, there's also tcp-2.6 but 
> > it's currently a bit outdated).
> 
> Thanks for your suggestion. SACK processing has a heavy workload and 
> it is complex. I agree to make efforts toward a more generic solution. 
> Your recv_sack_cache patch seems valuable.

Agreed, and as is, it's getting more and more expensive to do. The current 
code is doing more and more processing compared to how much new SACK 
information was actually received. ...However, doing a large surgery like 
that and maintaining full correctness at the same time scares me a bit...

-- 
 i.