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]

Date:	Tue, 11 May 2010 10:06:27 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	stern@...land.harvard.edu
Cc:	dwmw2@...radead.org, fujita.tomonori@....ntt.co.jp,
	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 Mon, 10 May 2010 10:58:37 -0400 (EDT)
Alan Stern <stern@...land.harvard.edu> wrote:

> On Mon, 10 May 2010, David Woodhouse wrote:
> 
> > On Mon, 2010-05-10 at 11:50 +0900, FUJITA Tomonori wrote:
> > > On Fri, 7 May 2010 10:51:10 -0400 (EDT)
> > > Alan Stern <stern@...land.harvard.edu> wrote:
> > > 
> > > > On Fri, 7 May 2010, Daniel Mack wrote:
> > > > 
> > > > > > At least the audio class and ua101 drivers don't do this and fill the
> > > > > > buffers before they are submitted.
> > > > > 
> > > > > Gnaa, you're right. I _thought_ my code does it the way I described, but
> > > > > what I wrote is how I _wanted_ to do it, not how it's currently done. I
> > > > > have a plan to change this in the future.
> > > > > 
> > > > > So unfortunately, that doesn't explain it either. Sorry for the noise.
> > > > 
> > > > At one point we tried an experiment, printing out the buffer and DMA 
> > > > addresses.  I don't recall seeing anything obviously wrong, but if an 
> > > > IOMMU was in use then that might not mean anything.  Is it possible 
> > > > that the IOMMU mappings sometimes get messed up for addresses above 4 
> > > > GB?
> > > 
> > > You mean that an IOMMU could allocate an address above 4GB wrongly? If
> > > so, IIRC, all the IOMMU implementations use dev->dma_mask and
> > > dev->coherent_dma_mask properly. And the DMA address space of the
> > > majority of IOMMUs are limited less than 4GB.
> > 
> > The Intel IOMMU code will use dev->dma_mask and dev->coherent_dma_mask
> > properly. It is not limited to 4GiB, but it will tend to give virtual
> > DMA addresses below 4GiB even when a device is capable of more; it'll
> > only give out higher addresses when the address space below 4GiB is
> > exhausted.
> 
> What I meant was: Is it possible that the IOMMU code will return a
> virtual DMA address before 4 GB but will somehow forget to actually map
> that address to the data buffer?

Then, the IOMMU is completely broken. Then, we would get tons of DMA
bugs not only about USB, I guess. So I'm not sure.


> 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.
--
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/