[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7430889f4409400fa3057d3e95ce8c34@AcuMS.aculab.com>
Date: Tue, 21 Nov 2017 12:17:20 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Jon Maloy' <jon.maloy@...csson.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC: "mohan.krishna.ghanta.krishnamurthy@...csson.com"
<mohan.krishna.ghanta.krishnamurthy@...csson.com>,
"tung.q.nguyen@...tech.com.au" <tung.q.nguyen@...tech.com.au>,
"hoang.h.le@...tech.com.au" <hoang.h.le@...tech.com.au>,
"canh.d.luu@...tech.com.au" <canh.d.luu@...tech.com.au>,
"ying.xue@...driver.com" <ying.xue@...driver.com>,
"tipc-discussion@...ts.sourceforge.net"
<tipc-discussion@...ts.sourceforge.net>
Subject: RE: [net-next 1/1] tipc: enforce valid ratio between skb truesize
and contents
From: Jon Maloy
> Sent: 15 November 2017 20:24
> The socket level flow control is based on the assumption that incoming
> buffers meet the condition (skb->truesize / roundup(skb->len) <= 4),
> where the latter value is rounded off upwards to the nearest 1k number.
> This does empirically hold true for the device drivers we know, but we
> cannot trust that it will always be so, e.g., in a system with jumbo
> frames and very small packets.
I'd be more worried about drivers that set skb->truesize to the amount
of data in the skb rather than the memory used by the skb.
Last I looked some of the usbnet drivers lied badly.
David
Powered by blists - more mailing lists