linux-kernel - Re: Scatter-gather list constraints

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.0806231522500.30973-100000@iolanthe.rowland.org>
Date:	Mon, 23 Jun 2008 15:45:05 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	David Vrabel <david.vrabel@....com>
cc:	Kernel development list <linux-kernel@...r.kernel.org>,
	AntonioLin <antonio.lin@...ormicro.com>,
	<linux-usb@...r.kernel.org>,
	"Perez-Gonzalez, Inaky" <inaky.perez-gonzalez@...el.com>
Subject: Re: Scatter-gather list constraints

On Mon, 23 Jun 2008, David Vrabel wrote:

> Alan Stern wrote:
> > On Mon, 23 Jun 2008, David Vrabel wrote:
> > 
> >> Note that this 1024 byte multiple is for one particular WUSB mass
> >> storage device.  The WUSB standard permits max packet sizes of up 3584
> >> (in multiples of 512), but I suspect WUSB mass storage devices will only
> >> use 512, 1024, or 2048.
> >>
> >> For a solution, we may be able to do something if the HWA host
> >> controller is passed a single URB with an s-g list (rather than one URB
> >> per s-g list entry) and was careful about how it segmented the URB into
> >> transfers to the rpipe.
> > 
> > That would be ideal.  However there is no way to pass an S-G list along 
> > with an URB; there's no field for it in the data structure.  And none 
> > of the existing host controller drivers support such a thing.
> > 
> > I suppose we could add a field to struct urb and add a flag indicating 
> > whether the controller driver supports S-G lists.
> 
> This is what I was thinking.
> 
> Can the number of entries in a sg list be limited?  e.g., if the
> hardware only had support for say, 64 entries?

Yes, there are two fields in struct request_queue for this: 
max_phys_segments (the driver's limit) and max_hw_segments (the 
hardware's limit).

Standard EHCI hardware requires that the memory locations of the data
for each packet be "virtually contiguous", i.e., discontiguities are
allowed only at 4-KB page boundaries.  This severely limits the ability
to handle general S-G lists.  For example, a 1024-byte packet can't be
broken up into two 512-byte pieces unless the first piece ends at a
page boundary and the second piece begins at a page boundary.  Maybe
HWA host controllers are required to be more flexible, I don't know.

This may mean that your suggested approach won't work.

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/