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, 19 May 2009 17:40:20 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Grant Grundler <grundler@...gle.com>
Cc:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>, jgarzik@...ox.com,
	hancockrwd@...il.com, htejun@...il.com, alan@...rguk.ukuu.org.uk,
	flar@...andria.com, schmitz@...phys.uni-duesseldorf.de,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org,
	takata@...ux-m32r.org, geert@...ux-m68k.org,
	linux-m68k@...r.kernel.org, ysato@...rs.sourceforge.jp
Subject: Re: [PATCH] asm-generic: add a dma-mapping.h file

On Tuesday 19 May 2009 17:01:27 Grant Grundler wrote:
> On Tue, May 19, 2009 at 9:22 AM, Arnd Bergmann <arnd@...db.de> wrote:
> I've reviewed the first bit and it looks fine (so far to me).
> Two related bugs:
> 1) dma_alloc_coherent() is not respecting the coherent_dma_mask field
> in device.h:struct device.

Hmm, I've taken that function unchanged from powerpc. I guess that means
that powerpc is broken  here as well, right?

> 2) dma_map_single() is not respecting dma_mask in struct pci_dev (and
> pointer from struct device).

What should it do with the mask? All the architectures I've looked
at as well as arch/parisc/kernel/pci-dma.c ignore it.
Should dma_map_* just fail in case of an address exceeding dma_mask?

> > +/**
> > + * dma_alloc_coherent - allocate consistent memory for DMA
> > + * @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
> > + * @size: required memory size
> > + * @handle: bus-specific DMA address
> > + *
> > + * Allocate some uncached, unbuffered memory for a device for
> > + * performing DMA.  This function allocates pages, and will
> > + * return the CPU-viewed address, and sets @handle to be the
> > + * device-viewed address.
> 
> Key here is the DMA is coherent, bi-directional, and the DMA address fit in
> the coherent_dma_mask. "uncached/unbuffered" is one way of doing this and
> is how we've implemented "DMA coherency" on parisc platforms that don't
> have an IOMMU (which all have PA1.1 CPUs) - see arch/parisc/kernel/pci-dma.c

All the architectures I've looked at come with their own version of _alloc_coherent
that works in similar ways to allocate an uncached mapping. Now that you
mention this, I realize that there is a bug on cris, which after my patch either
has two conflicting implementations of dma_{alloc,free}_coherent, or
is missing the dma_coherent_dev() function that is hidden inside of the
same #ifdef. The one in arch/cris/arch-v32/drivers/pci/dma.c does seem
to be correct though.

	Arnd <><
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ