aboutsummaryrefslogtreecommitdiffstats
path: root/net/ipv4/tcp_input.c
diff options
context:
space:
mode:
authorIlpo Järvinen <ilpo.jarvinen@helsinki.fi>2007-10-01 18:28:17 -0400
committerDavid S. Miller <davem@sunset.davemloft.net>2007-10-10 19:53:59 -0400
commit0e835331e3111e5a92eb3a852405ea71ca8fff97 (patch)
treee7c1445866cf4ed306ffd39e1fd520f2b761566a /net/ipv4/tcp_input.c
parent95eacd27e2a0924f1435654c06712cee6be099ad (diff)
[TCP]: Update comment of SACK block validator
Just came across what RFC2018 states about generation of valid SACK blocks in case of reneging. Alter comment a bit to point out clearly. IMHO, there isn't any reason to change code because the validation is there for a purpose (counters will inform user about decision TCP made if this case ever surfaces). Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/ipv4/tcp_input.c')
-rw-r--r--net/ipv4/tcp_input.c11
1 files changed, 9 insertions, 2 deletions
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 904289d2b6bb..c1339d88bbf3 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1027,8 +1027,15 @@ static void tcp_update_reordering(struct sock *sk, const int metric,
1027 * SACK block range validation checks that the received SACK block fits to 1027 * SACK block range validation checks that the received SACK block fits to
1028 * the expected sequence limits, i.e., it is between SND.UNA and SND.NXT. 1028 * the expected sequence limits, i.e., it is between SND.UNA and SND.NXT.
1029 * Note that SND.UNA is not included to the range though being valid because 1029 * Note that SND.UNA is not included to the range though being valid because
1030 * it means that the receiver is rather inconsistent with itself (reports 1030 * it means that the receiver is rather inconsistent with itself reporting
1031 * SACK reneging when it should advance SND.UNA). 1031 * SACK reneging when it should advance SND.UNA. Such SACK block this is
1032 * perfectly valid, however, in light of RFC2018 which explicitly states
1033 * that "SACK block MUST reflect the newest segment. Even if the newest
1034 * segment is going to be discarded ...", not that it looks very clever
1035 * in case of head skb. Due to potentional receiver driven attacks, we
1036 * choose to avoid immediate execution of a walk in write queue due to
1037 * reneging and defer head skb's loss recovery to standard loss recovery
1038 * procedure that will eventually trigger (nothing forbids us doing this).
1032 * 1039 *
1033 * Implements also blockage to start_seq wrap-around. Problem lies in the 1040 * Implements also blockage to start_seq wrap-around. Problem lies in the
1034 * fact that though start_seq (s) is before end_seq (i.e., not reversed), 1041 * fact that though start_seq (s) is before end_seq (i.e., not reversed),