[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANn89iKyw-xBP8Ao7TRZ0bE++0JP5g7dwkY8SL9JRYB4VY+waQ@mail.gmail.com>
Date: Thu, 16 Jan 2020 18:59:04 -0800
From: Eric Dumazet <edumazet@...gle.com>
To: "Li,Rongqing" <lirongqing@...du.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFC] tcp: remove BUG_ON in tcp_shifted_skb
On Thu, Jan 16, 2020 at 6:03 PM Li,Rongqing <lirongqing@...du.com> wrote:
>
> I think this BUG_ON in tcp_shifted_skb maybe be triggered if a GSO skb is
> sacked, but sack is faked, and not ack the whole mss length, only ack less
> than mss length
>
> Is it possible ?
I doubt it. Please provide a packetdrill test if you think otherwise.
>
> - Li RongQing <lirongqing@...du.com>
>
> ---
> net/ipv4/tcp_input.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 1d1e3493965f..141bc85092b5 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -1327,7 +1327,8 @@ static bool tcp_shifted_skb(struct sock *sk, struct sk_buff *prev,
> TCP_SKB_CB(prev)->sacked |= (TCP_SKB_CB(skb)->sacked & TCPCB_EVER_RETRANS);
>
> if (skb->len > 0) {
> - BUG_ON(!tcp_skb_pcount(skb));
I understand people can be worried about BUG_ON(), but they serve to
spot bugs when a patch breaks something horribly.
Powered by blists - more mailing lists