linux-kernel - RE: [PATCH] net: usb: allow MTU that is a multiple of USB packet size

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 for Android: free password hash cracker in your pocket

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

Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1CB2F70B@AcuExch.aculab.com>
Date:	Thu, 7 May 2015 16:19:45 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Oliver Neukum' <oneukum@...e.de>,
	Ruslan Bilovol <ruslan.bilovol@...il.com>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] net: usb: allow MTU that is a multiple of USB packet
 size

From: Oliver Neukum
> Sent: 07 May 2015 11:11
> On Thu, 2015-05-07 at 12:49 +0300, Ruslan Bilovol wrote:
> > Current usbnet driver rejects setting MTU that is a multiple
> > of USB endpoint's wMaxPacketSize size. However, it may only
> > lead to possible performance degradation but is not so
> > critical that its using should be prohibited. So allow it
> > but also warn user about possible issue.
> 
> We have reports about devices reacting badly to ZLPs.
> Unless you have a compelling reasons for this change
> I have to reject it.

I don't remember seeing a fix for xhci to even send ZLP go through.
If the ZLP are sent then the device will behave badly.

The receive side code in usbnet also needs a lot of TLC.
(I don't remember anything major happening to it in the last couple
of years.)
I think it would be better if it didn't try to use skb for receive URB.
Instead it should supply URB that are always multiples of the USB
buffer size and then generate receive skb from the receive USB data.
This would require code that correctly processes ethernet frames that
span URB boundaries.
This would remove the need for the 16k+ sized skb used by some of the
sub-drivers and the typical lying about the 'true size'.

For xhci it really ought to be possible to remove a lot of code from the
tx and rx data paths and just write the buffer descriptors directly into
the ring entries (as is a typical ethernet driver).
That might get the performance (and software overhead) of USB3 Ge much
nearer that of a normal ethernet device.

	David