Suspicious fackets_out handling

["Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>]

Hi,


While looking through the users of fackets_out, i found this from 
tcp_fragment(...):

	/* If this packet has been sent out already, we must
         * adjust the various packet counters.
         */
        if (!before(tp->snd_nxt, TCP_SKB_CB(buff)->end_seq)) {
		int diff = old_factor - tcp_skb_pcount(skb) -
                        tcp_skb_pcount(buff);

		[...snip...]

		if (diff > 0) {
                        /* Adjust Reno SACK estimate. */
                        if (!tp->rx_opt.sack_ok) {
                                tp->sacked_out -= diff;
                                if ((int)tp->sacked_out < 0)
                                        tp->sacked_out = 0;
                                tcp_sync_left_out(tp);
                        }

                        tp->fackets_out -= diff;
                        if ((int)tp->fackets_out < 0)
                                tp->fackets_out = 0;
                }
	}
	[...]

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)... 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. 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.


-- 
 i.