Fix TCP's ->fastpath_cnt_hit handling.
commit692767dfebce10bc997073eb707a934348cdfe08
authorIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
Wed, 10 Oct 2007 10:25:53 +0000 (10 03:25 -0700)
committerGreg Kroah-Hartman <gregkh@suse.de>
Fri, 2 Nov 2007 15:44:11 +0000 (2 08:44 -0700)
tree0a02ad44b95335085588de4d867c81c431e91d43
parente43358c5c81a6b7be8d55af6d736e05aa3d8ceb7
Fix TCP's ->fastpath_cnt_hit handling.

changeset 48611c47d09023d9356e78550d1cadb8d61da9c8 in mainline.

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>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
net/ipv4/tcp_input.c