Commit 48611c47d09023d9356e78550d1cadb8d61da9c8

Authored by Ilpo Järvinen
Committed by David S. Miller
1 parent 3eb215de26

[TCP]: Fix fastpath_cnt_hint when GSO skb is partially ACKed

When only GSO skb was partially ACKed, no hints are reset,
therefore fastpath_cnt_hint must be tweaked too or else it can
corrupt fackets_out. The corruption to occur, one must have
non-trivial ACK/SACK sequence, so this bug is not very often
that harmful. There's a fackets_out state reset in TCP because
fackets_out is known to be inaccurate and that fixes the issue
eventually anyway.

In case there was also at least one skb that got fully ACKed,
the fastpath_skb_hint is set to NULL which causes a recount for
fastpath_cnt_hint (the old value won't be accessed anymore),
thus it can safely be decremented without additional checking.

Reported by Cedric Le Goater <clg@fr.ibm.com>

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>

Showing 1 changed file with 3 additions and 0 deletions Side-by-side Diff

net/ipv4/tcp_input.c
... ... @@ -2420,6 +2420,9 @@
2420 2420 __u32 dval = min(tp->fackets_out, packets_acked);
2421 2421 tp->fackets_out -= dval;
2422 2422 }
  2423 + /* hint's skb might be NULL but we don't need to care */
  2424 + tp->fastpath_cnt_hint -= min_t(u32, packets_acked,
  2425 + tp->fastpath_cnt_hint);
2423 2426 tp->packets_out -= packets_acked;
2424 2427  
2425 2428 BUG_ON(tcp_skb_pcount(skb) == 0);