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
| ||
|
Date: Thu, 30 Jan 2014 17:17:21 +0100 From: Peter Stuge <peter@...ge.se> To: David Laight <David.Laight@...LAB.COM> Cc: "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, Sarah Sharp <sarah.a.sharp@...ux.intel.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, David Miller <davem@...emloft.net> Subject: Re: [PATCH RFC 1/1] usb: Tell xhci when usb data might be misaligned David Laight wrote: > Some xhci (USB3) controllers have a constraint on the offset within a > bulk transfer of the end of the transfer ring. Mhm. > code using libusb can generate arbitrarily long transfers that usually > get split into 8k fragments. libusb splits transfers into 16k urbs, or doesn't with newer code when both kernel and libusb support scatter-gather. > In fact libusb always uses 8k fragments. Hm? Worst-case libusb-1.0 submits 16k urbs. libusb-0.1 I'm unsure about, but could check. When both sides support it, scatter-gather is used and a single urb is submitted. IIRC usbfs doesn't mess with urb buffers at all. Where's the 8k coming from? > This all means that the xhci driver needs to accept unlimited numbers > of 'aligned' fragments and only restrict the number of misaligned ones. libusb applications have so far never made efforts to align their buffers to anything. That seems to become relevant for zero-copy? //Peter -- 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