netdev - Re: [REGRESSION, bisect]cxgb4 port failure with TSO traffic after commit 10d3be569243def8("tcp-tso: do not split TSO packets at retransmit time")

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANn89i+ePpSDYPtQeZa=fdN84=4WKdDb88P-dOVyPyY_DMK02g@mail.gmail.com>
Date:	Fri, 24 Jun 2016 07:25:53 -0700
From:	Eric Dumazet <edumazet@...gle.com>
To:	"Arjun V." <arjun@...lsio.com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Hariprasad S <hariprasad@...lsio.com>,
	Casey Leedom <leedom@...lsio.com>,
	Kumar A S <kumaras@...lsio.com>,
	Santosh Rastapur <santosh@...lsio.com>,
	Nirranjan Kirubaharan <nirranjan@...lsio.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"ycheng@...gle.com" <ycheng@...gle.com>
Subject: Re: [REGRESSION, bisect]cxgb4 port failure with TSO traffic after
 commit 10d3be569243def8("tcp-tso: do not split TSO packets at retransmit time")

Please do not top post on netdev mailing list

On Fri, Jun 24, 2016 at 4:38 AM, Arjun V. <arjun@...lsio.com> wrote:
> Eric,
> We are seeing skb's with length(skb->len) greater than 65536 coming into our ndo_start_xmit() callback routine.
> We can add a check in our eth_xmit() routine to skip those packets, but it will be better if you fix this in kernel.
>
>
> I have attached pcap file obtained from tcpdump. In the pcap file there are 2 such packets(I used tcpdump filter to extract out those packets).
>
> Let us know if you need anything else.
>

Beats me really.

At retransmit time, we only can eventually reduce packet sizes
(assuming GSO is used, because we might coalesce sub-mss packets in
tcp_retrans_try_collapse())

So why are you seeing too big packets at retransmit, I really have no idea.

MIght be some bug related to MSS computation, overflowing somehow ?