linux-kernel - Re: [alsa-devel] USB transfer_buffer allocations on 64bit systems

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: <20100511232216R.fujita.tomonori@lab.ntt.co.jp>
Date:	Tue, 11 May 2010 23:22:24 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	stern@...land.harvard.edu
Cc:	fujita.tomonori@....ntt.co.jp, dwmw2@...radead.org,
	daniel@...aq.de, clemens@...isch.de, tiwai@...e.de,
	alsa-devel@...a-project.org, gregkh@...e.de,
	konrad.wilk@...cle.com, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org, chrisw@...s-sol.org,
	iommu@...ts.linux-foundation.org, andi@...stfloor.org,
	pedrib@...il.com, akpm@...ux-foundation.org
Subject: Re: [alsa-devel] USB transfer_buffer allocations on 64bit systems

On Tue, 11 May 2010 10:00:50 -0400 (EDT)
Alan Stern <stern@...land.harvard.edu> wrote:

> > > The problem goes away when Pedro boots with mem=4G.  And the dma_mask
> > > value is set properly (in fact, the ehci-hcd driver currently doesn't
> > > use 64-bit DMA at all).
> > > 
> > > If anyone wants to see the debug log entries showing the buffer and DMA
> > > addresses, they are attached to this email message:
> > > 
> > > 	http://marc.info/?l=linux-kernel&m=127076841801054&w=2
> > > 
> > > Either the data isn't getting written to the buffer correctly or else
> > > the buffer isn't getting sent to the device correctly.  Can anybody
> > > suggest a means of determining which is the case?
> > 
> > I can't say anything about this log that including only DMA addresses.
> > I'm not familiar with how the USB core does DMA stuff. And the USB
> > stack design that the USB core does DMA stuff (allocating, mappings,
> > etc) makes debugging DMA issues really difficult.
> 
> The DMA stuff is simple enough in this case.  The urb->transfer_buffer
> address is passed to dma_map_single(), and the DMA address it returns
> is stored in urb->transfer_dma.  Those are the two values printed out
> by the debugging patch.

You've already confirmed that all the returned addresses
(urb->transfer_dma) in the log is less than 4GB, right?

Drivers need to take care of more things (not only about addresses) to
do DMA properly, that is, use the DMA API in the proper way (such as,
once calling dma_map_single, drivers can't touch the buffer until
calling dma_unmap_single)

Using the DMA API and performing DMA transfer in different places just
make things complicated.
--
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/