netdev - Re: [net-next 03/12] i40e: Handle a single mss packet with more than 8 frags

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: <1416321201.14060.20.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Tue, 18 Nov 2014 06:33:21 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	David Laight <David.Laight@...LAB.COM>
Cc:	"'Nelson, Shannon'" <shannon.nelson@...el.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"Kong, Serey" <serey.kong@...el.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"nhorman@...hat.com" <nhorman@...hat.com>,
	"sassmann@...hat.com" <sassmann@...hat.com>,
	"jogreene@...hat.com" <jogreene@...hat.com>
Subject: Re: [net-next 03/12] i40e: Handle a single mss packet with more
 than 8 frags

On Tue, 2014-11-18 at 09:46 +0000, David Laight wrote:

> That isn't entirely clear from the patch context.

gso_segs = 1 was not clear ???

gso_segs = 1;
if (skb_shinfo(skb)->nr_frags >= I40E_MAX_BUFFER_TXD)
	skb_linearize(skb);


Nelson, what happens if a packet has 2 segments and uses 17 fragments ?
Is the hardware OK with that ?

netperf -t TCP_SENDFILE -- -m 171

I did the test and it seems fine on my host, but maybe it was pure luck.

While the following indeed froze the card :

netperf -H 7.7.7.27 -t TCP_SENDFILE -- -m 30


[3257268.702689] i40e 0000:84:00.0: requesting a pf reset
[3257268.831786] i40e 0000:84:00.0: i40e_ptp_init: added PHC on eth2
[3257268.912798] i40e 0000:84:00.0 eth2: NIC Link is Up 40 Gbps Full Duplex, Flow Control: RX/TX
[3257338.895753] i40e 0000:84:00.0: Detected Tx Unit Hang
[3257338.895753]   VSI                  <518>
[3257338.895753]   Tx Queue             <16>
[3257338.895753]   next_to_use          <17c>
[3257338.895753]   next_to_clean        <b2>
[3257338.895757] i40e 0000:84:00.0: tx_bi[next_to_clean]
[3257338.895757]   time_stamp           <1c20f09c9>
[3257338.895757]   jiffies              <1c20f0eac>
[3257338.895759] i40e 0000:84:00.0: tx hang detected on queue 16, resetting adapter
[3257338.895769] i40e 0000:84:00.0 eth2: tx_timeout recovery level 1
[3257338.895926] i40e 0000:84:00.0: i40e_vsi_control_tx: VSI seid 518 Tx ring 0 disable timeout
[3257338.949922] i40e 0000:84:00.0: i40e_vsi_control_tx: VSI seid 520 Tx ring 64 disable timeout
[3257339.410705] i40e 0000:84:00.0: PF reset failed, -15

> 
> For a non-TSO packet the skb_serialize() is less likely to fail
> since it doesn't need contiguous pages.

Any memory allocation can fail, regardless of the size.
We do not want a memory stress being able to crash the host,
likely or not. It is not worth discussing this, really.


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html