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.1407021630340.874-100000@iolanthe.rowland.org>
Date:	Wed, 2 Jul 2014 16:40:27 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Peter Stuge <peter@...ge.se>
cc:	Stefan Klug <stefan.klug@...lerweb.com>,
	<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH][RFC] USB: zerocopy support for usbfs

On Wed, 2 Jul 2014, Peter Stuge wrote:

> > The kernel doesn't support scatter-gather for control transfers, only 
> > bulk.
> 
> That could possibly change, right, and then it would be nice to have
> zerocopy for free there as well?

No.  ohci-hcd doesn't support control transfers larger than 4 KB
anyway, and ehci-hcd doesn't support control transfers larger than 16 
KB.  This is not likely to change.  Besides, a control transfer can 
never be larger than 64 KB, and throughput isn't an issue for them.

> > > Indeed I think userspace wants to be involved in choosing memory also
> > > with bulk, in order to ensure that zerocopy will always work when
> > > userspace cares about that.
> > > 
> > > Is it enough to expose the DMA mask of the host controller?
> > 
> > It doesn't need to be exposed, since the mmap(2) call would be handled
> > by the kernel's USB stack (and besides, the user program can't request
> > that the mapped memory be located in any particular physical address
> > region).
> 
> Since alignment isn't the only issue I don't think there's a way to
> avoid it. I was just hoping to be able to avoid allocating zerocopy
> buffers with mmap().

How else can you guarantee that a buffer is located in the first 4 GB
of memory?  Even on a 32-bit system (if the computer has more than 4 GB 
of RAM)?

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