linux-kernel - Re: [PATCH] usb: core: allow zero packet flag for interrupt urbs

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:	Thu, 17 Jul 2014 13:59:48 -0700
From:	Steve Calfee <stevecalfee@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
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, Jul 17, 2014 at 12:32 PM, Alan Stern <stern@...land.harvard.edu> wrote:
> On Thu, 17 Jul 2014, Steve Calfee wrote:
>
>> Hi Alan,
>>
>> I did some testing with multi interrupt transfers some time ago. You
>> can get allocated a guaranteed 3x1024 time slot per uframe for an
>> interval of your choice on usb 2.0. So zlps are needed to send exactly
>> 1024 or 2048 bytes in that time slot.
>
> That's true, but misleading.  Use of zero-length packets is relatively
> independent of the time slot divisions.  zlps are necessary to mark the
> end of a multi-packet transfer; they aren't necessary if all you want
> to do is send less than 3072 bytes during a single 3x1024 time slot.
>
> Consider also that the URB_ZERO_PACKET flag will give you at most one
> zlp.  That won't be good enough if you want to send exactly 1024 bytes
> in the time slot; you would need two zlps.  Besides, why would you want
> to limit the amount of data that gets sent during the time slot?  If
> you have more than 1024 or 2048 bytes, why not send all of it?
>
> (For that matter, what happens if you want to send 2000 bytes during
> the time slot?  The first packet will contain 1024 bytes, the second
> will contain the remaining 976, and there won't be a zlp even if
> URB_ZERO_PACKET is set.  Instead, the third packet will contain
> whatever data has been queued next.  I was a little surprised to see
> that section 4.10.3 in the EHCI spec _doesn't_ say the controller must
> leave the Exercute Transaction state when a short packet is
> encountered -- even though not doing so would violate the USB-2.0
> spec.)
>
> Conversely, if you have only 1024 bytes to send, you don't need to do
> anything special.  Just send them.  There won't be any zlp during the
> time slot, but if no data is queued then nothing will be sent after
> those 1024 bytes.
>
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.

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.

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.

Regards, Steve
--
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/