netdev - RE: [PATCH] usb: xhci: Link TRB must not occur with a USB payload burst.

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: <AE90C24D6B3A694183C094C60CF0A2F6026B7428@saturn3.aculab.com>
Date:	Mon, 18 Nov 2013 09:48:52 -0000
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Ben Hutchings" <bhutchings@...arflare.com>
Cc:	"Alan Stern" <stern@...land.harvard.edu>,
	"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.

> > But the minimum fragment size is (probably) 4k.
> > For the network stack an OUT transfer might have a lot (and I mean lots)
> > of fragments (there may be constraints, and linearising the skb is a option).
> [...]
> 
> The maximum number of fragments in the skb is going to be 17 (including
> the 'head' area).  (I'm ignoring NETIF_F_FRAGLIST which is not normally
> supported by physical device drivers.)
> 
> I don't know how many fragments that can end up as, at the USB level.

If you assume that every fragment crosses a 64k boundary that would be 34.
OTOH I've not seen a fragment of a 64k TSO send crossing a 32k
boundary, and I think the 'head' area is constrained to be part of
a single (4k or larger) page.

Isn't there something odd about skb merged by receive offload?
I've not entirely sorted out the full structure of skb.

	David