netdev - RE: smsc95xx truesize badness

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: <063D6719AE5E284EB5DD2968C1650D6D1CAE6788@AcuExch.aculab.com>
Date:	Fri, 20 Feb 2015 10:24:48 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Steve Glendinning' <steve@...well.net>,
	netdev <netdev@...r.kernel.org>
CC:	popcorn mix <popcornmix@...il.com>,
	"eric.dumazet@...il.com" <eric.dumazet@...il.com>
Subject: RE: smsc95xx truesize badness

From: Steve Glendinning
> It seems smsc95xx is doing bad things with truesize in our receive loop.

IIRC the same is true of a lot of the usbnet drivers.

Really the way usbnet works needs a complete revist.

Allocating (eg) 16k skb for receive is just plain stupid in the first place.
Provided the URB are multiples of the USB buffer size what the card sends
as a single bulk message can be received into multiple URB.

I'm not entirely convinced that trying to receive into skb is a good idea.
Copybreak of short frames and passing up references to rx buffer fragments
for long frames is probably a better idea.
Even for 100M 'short' might be 1500!

For USB3 things are even worse.
A USB3 ethernet driver ought to be almost as fast as a normal driver.
After all the transmit buffer fragments just need writing into the
usb descriptor ring (with some non-obvious constraints the xhci driver
tends to ignore as well).
However the code paths through usbnet are horribly long.

	David