linux-kernel - Re: Allocating buffers for USB transfers (again)

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:	Thu, 7 Jul 2011 14:33:42 +0200
From:	Oliver Neukum <oliver@...kum.org>
To:	Daniel Mack <zonque@...il.com>
Cc:	linux-usb@...r.kernel.org, alsa-devel@...a-project.org,
	Takashi Iwai <tiwai@...e.de>,
	Clemens Ladisch <clemens@...isch.de>, florian@...kler.org,
	pedrib@...il.com, William Light <wrl@...est.net>,
	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org
Subject: Re: Allocating buffers for USB transfers (again)

Am Donnerstag, 7. Juli 2011, 13:53:46 schrieb Daniel Mack:
> Takashi recently posted a patch to the bugzilla entry which uses a
> different approach: it introduces a function to determine suitable GFP
> flags for USB devices, and passes __DMA32 to kmalloc() eventually.
> However, using this flags directly with the SLUB allocator is illegal
> and causes a BUG() in mm/slub.c, cache_grow().
> 
> The question now is how to proceed. I see three possible ways.
> 
> 1. Find a way to allocate 32bit-aware memory with kmalloc(), following
> Takashi's idea

That is not really a good idea, because many drivers have to deal with buffers
another subsystem has allocated.

> 2. Find out exactly why these machines fail to install bounce buffers
> or set up their IOMMU correctly

This is still the correct approach. Given the cause this cannot be a problem
only for audio. We need the root cause.

> 3. re-activate the currently disabled functions
> usb_buffer_{map,unmap,sync} functions and let the USB stack do the
> memory mapping

The USB stack does call the DMA mapping operations.

	Regards
		Oliver

PS:  Do you still see this if you enable 64bit DMA for EHCI?
--
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/