From 5d07cf128b9dcbf31605d9560e5dd16bcc46be8a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= Date: Mon, 1 Oct 2007 15:28:17 -0700 Subject: [PATCH] --- yaml --- r: 66859 b: refs/heads/master c: 0e835331e3111e5a92eb3a852405ea71ca8fff97 h: refs/heads/master i: 66857: 44c2e923b587d5a3654b56ea9edb217e2449601f 66855: c74a8d0b1e956b73be6ddb15edf2dbc441660f2d v: v3 --- [refs] | 2 +- trunk/net/ipv4/tcp_input.c | 11 +++++++++-- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/[refs] b/[refs] index f1a77e7f3850..e96adfdf6b75 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: 95eacd27e2a0924f1435654c06712cee6be099ad +refs/heads/master: 0e835331e3111e5a92eb3a852405ea71ca8fff97 diff --git a/trunk/net/ipv4/tcp_input.c b/trunk/net/ipv4/tcp_input.c index 904289d2b6bb..c1339d88bbf3 100644 --- a/trunk/net/ipv4/tcp_input.c +++ b/trunk/net/ipv4/tcp_input.c @@ -1027,8 +1027,15 @@ static void tcp_update_reordering(struct sock *sk, const int metric, * SACK block range validation checks that the received SACK block fits to * the expected sequence limits, i.e., it is between SND.UNA and SND.NXT. * Note that SND.UNA is not included to the range though being valid because - * it means that the receiver is rather inconsistent with itself (reports - * SACK reneging when it should advance SND.UNA). + * it means that the receiver is rather inconsistent with itself reporting + * SACK reneging when it should advance SND.UNA. Such SACK block this is + * perfectly valid, however, in light of RFC2018 which explicitly states + * that "SACK block MUST reflect the newest segment. Even if the newest + * segment is going to be discarded ...", not that it looks very clever + * in case of head skb. Due to potentional receiver driven attacks, we + * choose to avoid immediate execution of a walk in write queue due to + * reneging and defer head skb's loss recovery to standard loss recovery + * procedure that will eventually trigger (nothing forbids us doing this). * * Implements also blockage to start_seq wrap-around. Problem lies in the * fact that though start_seq (s) is before end_seq (i.e., not reversed),