linux-kernel - Re: [PATCH v2 13/29] nios2: DMA mapping API

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:	Wed, 30 Jul 2014 16:56:32 +0400
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Ley Foon Tan <lftan@...era.com>, linux-arch@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
	lftan.linux@...il.com, cltang@...esourcery.com
Subject: Re: [PATCH v2 13/29] nios2: DMA mapping API

On Tue, 2014-07-15 at 11:38 +0200, Arnd Bergmann wrote:
> More importantly: you do the same operation for both _for_cpu and _for_device.
> I assume your CPU can never do speculative cache prefetches, so it's not
> incorrect, but you do twice the number of invalidations and flushes that
> you need. 

That's not necessarily a correct assumption.  A lot of CPUs (x86, arm,
parisc) feel entitled to speculate provided they have a TLB entry.
Usually they don't just do it for a whim, so the cpu has to be doing
something to cause the speculation, like reading from an adjacent page.
However, for DMA you always have to assume the possibility (unless you
really, really know the architecture cannot).

Therefore the pattern should be (assuming your bus doesn't need some
kind of flush and all flushes are only for the CPU).

DMA_TO_DEVICE: flush before (_for_device) do nothing after (_for_cpu)

DMA_FROM_DEVICE: do nothing before (_for_device), invalidate after
(_for_cpu)

DMA_BIDIRECTIONAL: flush before (_for_device) and invalidate after
(_for_cpu).

James

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