linux-kernel - Re: [PATCH] asm-generic: add dma-mapping-linear.h

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, 4 Jun 2009 17:47:03 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc:	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH] asm-generic: add dma-mapping-linear.h

On Thursday 04 June 2009, FUJITA Tomonori wrote:
> On Thu, 4 Jun 2009 12:35:34 +0000
> Arnd Bergmann <arnd@...db.de> wrote:
> 
> > > > I do have branches in there that convert x86 and microblaze to use
> > > 
> > > x86? How can it use asm-generic-linear.h?
> > 
> > Not dma-mapping-linear.h, but a lot of other files in asm-generic. I have
> > a set of all the common header files in my tree, and x86 can e.g. use
> > ioctls.h, ipcbuf.h, mman.h, or types.h. For x86, it amounts to 15 files,
> > microblaze can use almost 50 of the generic files.
> 
> I see, but I'm not sure why dma-mapping-linear needs to be merged with
> them together.

It doesn't need to, but it would be much more convenient for me having
to go through the architectures only once. Some of the arch maintainers
are harder to get hold of than others.

> > 
> > I think it is technically correct, but there are two plausible ways of
> > doing it, I chose the one that requires slightly less code.
> > 
> > I call dma_cache_sync() for streaming mappings on dma_map_* and
> > dma_sync_*_for_device iff the mapping is noncoherent. AFAICT, this
> > is the same case as dma_alloc_noncoherent, which is expected to give
> > out a noncoherent mapping.
> 
> If I correctly understand DMA-API.txt, dma_alloc_noncoherent can
> return either consistent or non-consistent memory. On architectures
> that return consistent memory via dma_alloc_noncoherent,
> dma_cache_sync should be null. dma_cache_sync() is supposed to be used
> only with the returned buffers of dma_alloc_noncoherent().

Good point. This is unfortunately not what is implemented on many
architectures, which #define dma_alloc_noncoherent dma_alloc_coherent
but still provide a synchronizing operation in dma_cache_sync().

dma_alloc_noncoherent is actually only implemented on parisc, mips
and m68k.

However, I don't think I have the energy to fix this problem, but
I agree that it should be fixed eventually. I can leave out
the declarations of dma_{free,alloc}_coherent from dma-mapping-linear.h
so that the broken code remains in the architecture specific
files, and change all references to dma_cache_sync to something
else. The best I can think of is __dma_cache_sync() with the same
calling conventions as dma_cache_sync(). Does that make sense?

	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/