linux-kernel - Re: 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: <Pine.LNX.4.44L0.1004091155570.1852-100000@iolanthe.rowland.org>
Date:	Fri, 9 Apr 2010 12:01:27 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Pedro Ribeiro <pedrib@...il.com>
cc:	Daniel Mack <daniel@...aq.de>,
	Robert Hancock <hancockrwd@...il.com>,
	<linux-kernel@...r.kernel.org>, <akpm@...ux-foundation.org>,
	Greg KH <gregkh@...e.de>, <alsa-devel@...a-project.org>,
	<linux-usb@...r.kernel.org>
Subject: Re: USB transfer_buffer allocations on 64bit systems

On Fri, 9 Apr 2010, Pedro Ribeiro wrote:

> On 8 April 2010 17:57, Alan Stern <stern@...land.harvard.edu> wrote:
> > On Thu, 8 Apr 2010, Daniel Mack wrote:
> >
> >> > > AFAIK, the driver shouldn't have to worry about this at all. When the
> >> > > buffer gets DMA-mapped for the controller, the DMA mapping code should
> >> > > see that the device has a 32-bit DMA mask and either bounce or IOMMU-map
> >> > > the memory so that it appears below 4GB.
> >> >
> >> > That's true.  It would of course be more efficient for the buffer to be
> >> > allocated below 4 GB, but it should work okay either way.  Daniel, do
> >> > you have any idea why it fails?
> >>
> >> No, and I can't do real tests as I lack a 64bit machine. I'll do some
> >> more investigation later today, but for now the only explanation I have
> >> is that not the remapped DMA buffer is used eventually by the EHCI code
> >> but the physical address of the original buffer.
> >>
> >> It would of course be best to fix the whole problem at this level, if
> >> possible.
> >
> > It definitely needs to be fixed at this level.  But I still think it's
> > appropriate to have new USB core functions for allocating and
> > deallocating I/O memory.  The additional price is small compared to
> > constantly bouncing the buffers.
> >
> > Pedro, in the hope of tracking down the problem, can you apply this
> > patch and see what output it produces in the system log when the
> > "interference" happens?  (Warning: It will produce quite a lot of
> > output whenever you send data to the audio device -- between 500 and
> > 1000 lines per second.)

> Hi Alan,
> 
> here is the output of the patch you sent me when the interference is triggered.
> 
> The log is long, 1.3mb in size.

I don't see anything suspicious.  The transfer_buffer addresses repeat 
every 32 URBs, and the DMA addresses cycle almost entirely uniformly 
from 0x20000000 to 0x23ffffff in units of 0x2000 (there are a few gaps 
where the interval is a little bigger).

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/