From: dongchenchen dongchenchen2@huawei.com
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8GYWB CVE: NA
--------------------------------
This reverts commit 389055ab28760dd7b25c6996c6647b0a37e0a34e.
Signed-off-by: dongchenchen dongchenchen2@huawei.com --- net/ipv4/tcp_input.c | 13 ------------- 1 file changed, 13 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index f8b1ace50f7a..a12598dabb80 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -172,19 +172,6 @@ static void tcp_measure_rcv_mss(struct sock *sk, const struct sk_buff *skb) if (unlikely(len > icsk->icsk_ack.rcv_mss + MAX_TCP_OPTION_SPACE)) tcp_gro_dev_warn(sk, skb, len); - /* If the skb has a len of exactly 1*MSS and has the PSH bit - * set then it is likely the end of an application write. So - * more data may not be arriving soon, and yet the data sender - * may be waiting for an ACK if cwnd-bound or using TX zero - * copy. So we set ICSK_ACK_PUSHED here so that - * tcp_cleanup_rbuf() will send an ACK immediately if the app - * reads all of the data and is not ping-pong. If len > MSS - * then this logic does not matter (and does not hurt) because - * tcp_cleanup_rbuf() will always ACK immediately if the app - * reads data and there is more than an MSS of unACKed data. - */ - if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_PSH) - icsk->icsk_ack.pending |= ICSK_ACK_PUSHED; } else { /* Otherwise, we make more careful check taking into account, * that SACKs block is variable.