Commit 0e835331 authored by Ilpo Järvinen's avatar Ilpo Järvinen Committed by David S. Miller
Browse files

[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: default avatarIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parent 95eacd27

net/ipv4/tcp_input.c

+9 −2
Original line number Diff line number Diff line
@@ -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),

CRA Git | Maintained and supported by SUSTech CRA and CCSE