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  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, 27 Oct 2009 09:57:49 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Alex Williamson <alex.williamson@...com>
Cc:	dwmw2@...radead.org, iommu@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: [PATCH 1/5] dma: create dma_generic_alloc/free_coherent()

On Mon, Oct 26, 2009 at 05:24:58PM -0600, Alex Williamson wrote:
> Move dma_generic_alloc_coherent() out of x86 code and create
> corresponding dma_generic_free_coherent() for symmetry.  These
> can then be used by IOMMU drivers attempting to implement
> passthrough mode.
> 
Except that dma_generic_alloc_coherent() is only "generic" for platforms
with consistent DMA. Everyone else will need a cacheflush and potentially
a remap. It's not even obvious from looking at the consistent DMA
platforms that they'll be able to use it out of the box due to expecting
something other than page_address(), which all suggests that this is
better off remaining an x86-only routine.

This is also making changes to the DMA-API without any documentation
updates and without consulting with any other architecture people. If you
wish to make a proposal for a DMA-API addition, then this should be made
to linux-arch rather than hidden in an iommu patchset.

Beyond that, we presently have:

	- dma_alloc_coherent()
	- dma_alloc_noncoherent()
	- dma_alloc_from_coherent()

defined in the API. Making an addition to this for your fallback case
seems workable, but it's something that will have to be handled
differently for each architecture. You might be able to get away with
something generic enough to stash in drivers/base/dma-coherent.c, but
from a first look, I wouldn't count on it.

It was bad enough when the x86-specific flush_write_buffers() snuck in to
the "generic" dma mapping code, but this particular case is much more
problematic.
--
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/

Powered by blists - more mailing lists