From: "Ilpo_Järvinen" <redacted>
Date: Mon, 23 Apr 2007 14:28:21 +0300 (EEST)

There are IMHO two problems in it. First of all, nothing ensures that the 
skb TCP is fragmenting is actually below the forwardmost sack block (and 
thus is included to the fackets_out)...

Good catch, I agree with your analysis completely.

What I'm not sure of though, is how to fix this in net-2.6(.22), it
is due to the fact that there is no pointer/seq which can be used in
testing for it like in tcp-2.6 which has the highest_sack.

We can add highest_sack to 2.6.22 in order to fix a bug like this,
if necessary.

Second problem is even more obvious: if adjustment here is being
done and the sacktag code then uses fastpath at the arrival of the
next ACK, the sacktag code will use a stale value from
fastpath_cnt_hint and fails to notice all that math TCP did here
unless we start clearing fastpath_skb_hint.

Let's try not to clear fastpath_skb_hint here if possible :-)

Is it possible to update fastpath_cnt_hint properly perhaps?