tcp: fix comment for tp->highest_sack
authorNeal Cardwell <ncardwell@google.com>
Mon, 27 Feb 2012 22:52:52 +0000 (17:52 -0500)
committerDavid S. Miller <davem@davemloft.net>
Tue, 28 Feb 2012 20:06:33 +0000 (15:06 -0500)
There was an off-by-one error in the comments describing the
highest_sack field in struct tcp_sock. The comments previously claimed
that it was the "start sequence of the highest skb with SACKed
bit". This commit fixes the comments to note that it is the "start
sequence of the skb just *after* the highest skb with SACKed bit".

Signed-off-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
include/linux/tcp.h
include/net/tcp.h

index 46a85c9e1f25bebddd3a1887b30fb182dcf5b5e4..3c7ffdb40dc64ba62cd8f9586fd04d668c4a469c 100644 (file)
@@ -412,7 +412,8 @@ struct tcp_sock {
 
        struct tcp_sack_block recv_sack_cache[4];
 
-       struct sk_buff *highest_sack;   /* highest skb with SACK received
+       struct sk_buff *highest_sack;   /* skb just after the highest
+                                        * skb with SACKed bit set
                                         * (validity guaranteed only if
                                         * sacked_out > 0)
                                         */
index 42c29bfbcee34d8d6ada5d18533850d82973f352..2d80c291fffbad01828648c46df1da0f69763e49 100644 (file)
@@ -1364,8 +1364,9 @@ static inline void tcp_push_pending_frames(struct sock *sk)
        }
 }
 
-/* Start sequence of the highest skb with SACKed bit, valid only if
- * sacked > 0 or when the caller has ensured validity by itself.
+/* Start sequence of the skb just after the highest skb with SACKed
+ * bit, valid only if sacked_out > 0 or when the caller has ensured
+ * validity by itself.
  */
 static inline u32 tcp_highest_sack_seq(struct tcp_sock *tp)
 {