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.1003171050080.1734-100000@iolanthe.rowland.org>
Date:	Wed, 17 Mar 2010 11:22:01 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
cc:	James.Bottomley@...senPartnership.com,
	<linux-kernel@...r.kernel.org>
Subject: Re: dma_sync_sg_for_cpu applied to a single scatterlist element

On Wed, 17 Mar 2010, FUJITA Tomonori wrote:

> dma_sync_single_for_* can do a partial sync but dma_sync_sg_for_*
> doesn't support a partial sync.
> 
> 
> > So it isn't clear that dma_sync_sg_for_cpu(dev, sg, 1, dir) can be used
> > on a mapping created by dma_map_sg(dev, sg, n, dir),
> 
> You should not do (though it might work).
> 
> > and it isn't 
> > clear that dma_sync_single_for_cpu() can be used on a mapping created 
> > by dma_map_sg().
> 
> You should not do (though it might work).
> 
> 
> > But if you guys say it will work, I'll go ahead and use
> > dma_sync_single_for_cpu().
> > 
> 
> Well, it's undocumented. It might work but might not.

It's a real problem.  I need it to work correctly.

Here's the situation.  The USB controller drivers don't all support
scatter-gather operation.  So there's a library routine in the USB core
which calls dma_map_sg() and then creates a separate I/O request for
each scatterlist element.  The driver can process these requests one at
a time, and when they are all finished the library routine calls
dma_unmap_sg().

However...  For tracing purposes (usbmon -- like tcpdump but for USB),
we may need to copy the data from each I/O request's transfer buffer.  
Unfortunately, this copying is done as each request is submitted (for 
output) or as it completes (for input), at which times the buffers are 
all mapped for DMA.  That's the problem.

Would we be better off not using dma_map_sg() at all in this situation?
We could map each scatterlist buffer individually with dma_map_single()
as the request is submitted and then unmap the buffer when the request
completes, just like with non-sg transfers; then the problem wouldn't
arise.

Would there be any significant penalty for doing this?  I realize it
would prevent adjacent buffers from getting coalesced, but that's
probably okay.  Any other reason not to?

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