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]
Date:	Fri, 18 Jul 2014 10:34:08 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Steve Calfee <stevecalfee@...il.com>
cc:	Amit Virdi <amit.virdi@...com>,
	USB list <linux-usb@...r.kernel.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	<gregkh@...uxfoundation.org>, <rdunlap@...radead.org>,
	<ming.lei@...onical.com>, Hans de Goede <hdegoede@...hat.com>
Subject: Re: [PATCH] usb: core: allow zero packet flag for interrupt urbs

On Thu, 17 Jul 2014, Steve Calfee wrote:

> Hi Alan,
> 
> It has been a few years since I was doing this, but here is my
> understanding. If a device descriptor says x bytes should be reserved
> (1 to 3072), the host will allocate that much bandwidth. If the sender
> sends some number of bytes between 1 and 3072 (must be less than or
> equal to x allocation), everything is ok the receiver will know when
> the sender is done. But (as with bulk xfers) if exactly 1024 or 2048
> bytes is sent, the receiver will not know the xfer is done. So in
> those cases, just as in bulk, the sender needs to send a ZLP.

You're getting mixed up over two different ideas here: a transfer and
the data sent during a particular microframe.  They aren't the same.

Thus, the receiver does know when a microframe's worth of data is
finished, even if exactly 1024 or 2048 bytes were sent, because the
receiver knows when the microframe ends (it gets an SOF packet).

Conversely, if a short transfer's length is a multiple of the maxpacket
size then without a zlp the receiver won't know when the transfer is
finished -- even if the transfer ends up occupying 3072 bytes.  For 
example, suppose the receiver expects the transfer to be 4096 bytes, 
but the sender has only 3072 bytes of data to send.

> The receiver will request up to 3 int xfers (depending on x>2048 or x
> >1024), and will stop issuing requests  (on a host sender) on a short
> transfer or a full xfer.

In USB, receivers do not issue requests.  The host initiates all 
transfers.

> Timeslots are guaranteed reservations, but they are not automatically
> always used. Unused bandwidth in a uframe (after reserved uses what it
> wants) will be used as needed by bulk or control transfers.

Correct.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ