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: <Pine.LNX.4.44L0.1311081303460.1162-100000@iolanthe.rowland.org>
Date:	Fri, 8 Nov 2013 13:12:42 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	David Laight <David.Laight@...LAB.COM>
cc:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	<netdev@...r.kernel.org>, <linux-usb@...r.kernel.org>
Subject: RE: [PATCH] usb: xhci: Link TRB must not occur with a USB payload
 burst.

On Fri, 8 Nov 2013, David Laight wrote:

> > The whole idea of TD fragments is exceedingly cloudy.  The definition
> > doesn't make sense, and the spec doesn't say what the actual hardware
> > restrictions are, i.e., what is the underlying reality that the TD
> > fragment concept wants to express.
> 
> I think that a TD fragment boundary exists whenever a TRB/dma boundary
> lines up with the packet boundary.

The spec doesn't say that.

> > Even if you do your best to ignore the whole idea, there still appear
> > to be certain restrictions you need to obey.  In addition to the
> > question of where Link TRBs are allowed, you also have to worry about
> > TDs whose size isn't a multiple of the Max Burst Payload (MBP) size =
> > MaxBurstSize * MaxPacketSize.
> 
> I'm not certain what MaxBurstSize and MaxPacketSize are, but the important
> number is the MBP. I'm fairly sure that is the value returned by
> GET_MAX_PACKET() - 1024 for USB3 bulk endpoints.

GET_MAX_PACKET always returns MaxPacketSize, and for USB-3 bulk
endpoints, MaxPacketSize is always 1024.  MaxBurstSize can be anything
from 1 to 16.

> > According to my version of the spec (Rev 1.0, dated 5/21/2010), if a TD
> > is larger than the MBP and its length isn't a multiple of the MBP, then
> > the last MBP boundary in the TD must also be a TRB boundary.  This
> > follows from two statements in section 4.11.7.1:
> > 
> > 	If the TD Transfer Size is an even multiple of the MBP then all
> > 	TD Fragments shall define exact multiples of MBP data bytes.
> > 	If not, then only the last TD Fragment shall define less than
> > 	MBP data (or the Residue) bytes.
> 
> No, that doesn't stop there being only 1 TD fragment.
> (I think it means exact multiple of the MBP.)

Suppose, for example, the MBP is 1024.  If you have a TD with length
1500, and if it had only one fragment, the last (and only) fragment's
length would not less than the MBP and it would not be an exact 
multiple of the MBP.

I agree that the text is not as clear as it should be.

Alan Stern

--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ