aboutsummaryrefslogtreecommitdiff
path: root/arch/ia64/sn/include
diff options
context:
space:
mode:
authorHerbert Xu <herbert@gondor.apana.org.au>2005-08-10 18:32:36 -0700
committerDavid S. Miller <davem@davemloft.net>2005-08-10 18:32:36 -0700
commitb5da623ae9be680ea59f268eeb339f0acb2d88c4 (patch)
treeb41844950a11240000d74fb65ce9c4ea82ef2a17 /arch/ia64/sn/include
parentbc68552faad0e134eb22281343d5ae5a4873fa80 (diff)
[TCP]: Adjust {p,f}ackets_out correctly in tcp_retransmit_skb()
Well I've only found one potential cause for the assertion failure in tcp_mark_head_lost. First of all, this can only occur if cnt > 1 since tp->packets_out is never zero here. If it did hit zero we'd have much bigger problems. So cnt is equal to fackets_out - reordering. Normally fackets_out is less than packets_out. The only reason I've found that might cause fackets_out to exceed packets_out is if tcp_fragment is called from tcp_retransmit_skb with a TSO skb and the current MSS is greater than the MSS stored in the TSO skb. This might occur as the result of an expiring dst entry. In that case, packets_out may decrease (line 1380-1381 in tcp_output.c). However, fackets_out is unchanged which means that it may in fact exceed packets_out. Previously tcp_retrans_try_collapse was the only place where packets_out can go down and it takes care of this by decrementing fackets_out. So we should make sure that fackets_out is reduced by an appropriate amount here as well. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'arch/ia64/sn/include')
0 files changed, 0 insertions, 0 deletions