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: <m2n74fd948d1004081613n90408827s7c51ef572848fb1d@mail.gmail.com>
Date:	Fri, 9 Apr 2010 00:13:08 +0100
From:	Pedro Ribeiro <pedrib@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
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 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.)
>
> Alan Stern
>
>
>
> Index: 2.6.33/drivers/usb/core/hcd.c
> ===================================================================
> --- 2.6.33.orig/drivers/usb/core/hcd.c
> +++ 2.6.33/drivers/usb/core/hcd.c
> @@ -1395,6 +1395,10 @@ int usb_hcd_submit_urb (struct urb *urb,
>                usbmon_urb_submit_error(&hcd->self, urb, status);
>                goto error;
>        }
> +       if (usb_endpoint_is_isoc_out(&urb->ep->desc))
> +               dev_info(&urb->dev->dev, "Iso xfer %p dma %llx\n",
> +                               urb->transfer_buffer,
> +                               (unsigned long long) urb->transfer_dma);
>
>        if (is_root_hub(urb->dev))
>                status = rh_urb_enqueue(hcd, urb);
>
>

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.

Please let me know if you need anything more.

Regards,
Pedro

Download attachment "iso.xfer.tar.bz2" of type "application/x-bzip2" (80439 bytes)