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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090601105851.GB25391@flint.arm.linux.org.uk>
Date:	Mon, 1 Jun 2009 11:58:51 +0100
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH] asm-generic: add dma-mapping-linear.h

On Mon, Jun 01, 2009 at 11:41:32AM +0100, Arnd Bergmann wrote:
> On Monday 01 June 2009, Russell King wrote:
> 
> > So, on a non-DMA coherent cache architecture, when DMA is normally
> > performed the data ends up in RAM with the cache flushed for that
> > region.  If, instead dma_map_single uses a bounce buffer to do that
> > DMA, then the same needs to be true of the original buffer - the
> > data needs to be in RAM with the cache flushed.
> 
> While this seems logical from a correctness perspective, I would
> like to understand why it actually matters. Flushing the cache on
> the original buffer will impact performance but doesn't generally
> make a difference to users. In cases where you need the cache
> to be flushed for aliasing reasons (VIPT caches...), the architecture
> specific code should flush that buffer somewhere, but do we really
> need to flush it for all architectures?

I didn't say "for all architectures".  I said that the end conditions
need to be the same no matter how DMA is done.

And yes, it does matter with some cache types.  VIPT aliasing caches
and VIVT caches both need to ensure that condition is met, otherwise
userspace doesn't see the data.

While we can hand-wave and say "some other part of the code should
handle this" I've had that disucssion several times, and that's where
this requirement eventually was stated.  And, really, I'm not going
to re-discuss it yet again - I really don't have time or motivation
at present to be involved in yet another hand-waving egotistical
debate over it.

Last time I got accused of not being helpful because I wouldn't test
a patch - and the reason I couldn't test the patch was because I don't
have the hardware which exhibited the problem.  Duh.

So, let's leave sleeping dogs to continue their deep sleep.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
--
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/