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] [day] [month] [year] [list]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ