linux-kernel - Re: [PATCH] tile,mn10300: add device parameter to dma_cache

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] [day] [month] [year] [list]

Date:	Fri, 8 Apr 2011 13:09:29 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	james@...anarts.com
Cc:	fujita.tomonori@....ntt.co.jp, dhowells@...hat.com,
	yasutake.koichi@...panasonic.com, cmetcalf@...era.com,
	akpm@...ux-foundation.org, james.hogan@...tec.com,
	konrad.wilk@...cle.com, lethal@...ux-sh.org, arnd@...db.de,
	linux-am33-list@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tile,mn10300: add device parameter to dma_cache_sync()

On Mon, 4 Apr 2011 20:50:41 +0100
James Hogan <james@...anarts.com> wrote:

> On Tue, Apr 05, 2011 at 02:50:40AM +0900, FUJITA Tomonori wrote:
> > On Mon, 4 Apr 2011 16:21:47 +0100
> > James Hogan <james@...anarts.com> wrote:
> > 
> > > From: James Hogan <james.hogan@...tec.com>
> > > 
> > > Note: I'm not in a position to compile test this patch, but I don't
> > > foresee any problems.
> > > 
> > > Since v2.6.20 "Pass struct dev pointer to dma_cache_sync()"
> > > (d3fa72e4556ec1f04e46a0d561d9e785ecaa173d), dma_cache_sync() takes a
> > > struct dev pointer, but these appear to be missing from the tile and
> > > mn10300 implementations, so add them.
> > > 
> > > Signed-off-by: James Hogan <james.hogan@...tec.com>
> > > ---
> > >  arch/mn10300/include/asm/dma-mapping.h |    2 +-
> > >  arch/tile/include/asm/dma-mapping.h    |    3 ++-
> > >  arch/tile/kernel/pci-dma.c             |    2 +-
> > >  3 files changed, 4 insertions(+), 3 deletions(-)
> > 
> > Looks fine (I don't even compile it though).
> > 
> > btw, mn10300's dma_cache_sync looks wrong.
> > 
> > DMA-API says:
> > 
> > Do a partial sync of memory that was allocated by
> > dma_alloc_noncoherent(), starting at virtual address vaddr and
> > continuing on for size.  Again, you *must* observe the cache line
> > boundaries when doing this.
> > 
> > looks like mn10300's dma_alloc_noncoherent() returns consistent
> > memory. So dma_cache_sync should be a null function.
> 
> I noticed it explicitly says:
> 442 Note: where the platform can return consistent memory, it will
> 443 guarantee that the sync points become nops.
> 
> I presume dma_cache_sync() is the "sync points" it is referring to.

I think that it's the "sync points" for architectures that return
either consistent or non-consistent memory.


> By the looks of it though the following architectures implement it but
> define the noncoherent functions to the coherent versions so shouldn't
> implement it (as far as I can tell):
>  avr,blackfin,frv,microblaze,powerpc,sh,unicore32,x86,xtensia

Yeah, I knew when I clean up the DMA API. But few uses
dma_cache_sync() so I left them alone.


> and ia64 says it isn't required so just does a full memory barrier
> instead (mb()).

I think that drivers need to care about such.
--
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/