| 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
| ||
|
Message-Id: <20230327121317.4081816-1-arnd@kernel.org>
Date: Mon, 27 Mar 2023 14:12:56 +0200
From: Arnd Bergmann <arnd@...nel.org>
To: linux-kernel@...r.kernel.org
Cc: Arnd Bergmann <arnd@...db.de>, Vineet Gupta <vgupta@...nel.org>,
Russell King <linux@...linux.org.uk>,
Neil Armstrong <neil.armstrong@...aro.org>,
Linus Walleij <linus.walleij@...aro.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, Guo Ren <guoren@...nel.org>,
Brian Cain <bcain@...cinc.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Michal Simek <monstr@...str.eu>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Dinh Nguyen <dinguyen@...nel.org>,
Stafford Horne <shorne@...il.com>,
Helge Deller <deller@....de>,
Michael Ellerman <mpe@...erman.id.au>,
Christophe Leroy <christophe.leroy@...roup.eu>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Rich Felker <dalias@...c.org>,
John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
"David S. Miller" <davem@...emloft.net>,
Max Filippov <jcmvbkbc@...il.com>,
Christoph Hellwig <hch@....de>,
Robin Murphy <robin.murphy@....com>,
Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
Conor Dooley <conor.dooley@...rochip.com>,
linux-snps-arc@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-oxnas@...ups.io,
linux-csky@...r.kernel.org, linux-hexagon@...r.kernel.org,
linux-m68k@...ts.linux-m68k.org, linux-mips@...r.kernel.org,
linux-openrisc@...r.kernel.org, linux-parisc@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, linux-riscv@...ts.infradead.org,
linux-sh@...r.kernel.org, sparclinux@...r.kernel.org,
linux-xtensa@...ux-xtensa.org
Subject: [PATCH 00/21] dma-mapping: unify support for cache flushes
From: Arnd Bergmann <arnd@...db.de>
After a long discussion about adding SoC specific semantics for when
to flush caches in drivers/soc/ drivers that we determined to be
fundamentally flawed[1], I volunteered to try to move that logic into
architecture-independent code and make all existing architectures do
the same thing.
As we had determined earlier, the behavior is wildly different across
architectures, but most of the differences come down to either bugs
(when required flushes are missing) or extra flushes that are harmless
but might hurt performance.
I finally found the time to come up with an implementation of this, which
starts by replacing every outlier with one of the three common options:
1. architectures without speculative prefetching (hegagon, m68k,
openrisc, sh, sparc, and certain armv4 and xtensa implementations)
only flush their caches before a DMA, by cleaning write-back caches
(if any) before a DMA to the device, and by invalidating the caches
before a DMA from a device
2. arc, microblaze, mips, nios2, sh and later xtensa now follow the
normal 32-bit arm model and invalidate their writeback caches
again after a DMA from the device, to remove stale cache lines
that got prefetched during the DMA. arc, csky and mips used to
invalidate buffers also before the bidirectional DMA, but this
is now skipped whenever we know it gets invalidated again
after the DMA.
3. parisc, powerpc and riscv already flushed buffers before
a DMA_FROM_DEVICE, and these get moved to the arm64 behavior
that does the writeback before and invalidate after both
DMA_FROM_DEVICE and DMA_BIDIRECTIONAL in order to avoid the
problem of accidentally leaking stale data if the DMA does
not actually happen[2].
The last patch in the series replaces the architecture specific code
with a shared version that implements all three based on architecture
specific parameters that are almost always determined at compile time.
The difference between cases 1. and 2. is hardware specific, while between
2. and 3. we need to decide which semantics we want, but I explicitly
avoid this question in my series and leave it to be decided later.
Another difference that I do not address here is what cache invalidation
does for partical cache lines. On arm32, arm64 and powerpc, a partial
cache line always gets written back before invalidation in order to
ensure that data before or after the buffer is not discarded. On all
other architectures, the assumption is cache lines are never shared
between DMA buffer and data that is accessed by the CPU. If we end up
always writing back dirty cache lines before a DMA (option 3 above),
then this point becomes moot, otherwise we should probably address this
in a follow-up series to document one behavior or the other and implement
it consistently.
Please review!
Arnd
[1] https://lore.kernel.org/all/20221212115505.36770-1-prabhakar.mahadev-lad.rj@bp.renesas.com/
[2] https://lore.kernel.org/all/20220606152150.GA31568@willie-the-truck/
Arnd Bergmann (21):
openrisc: dma-mapping: flush bidirectional mappings
xtensa: dma-mapping: use normal cache invalidation rules
sparc32: flush caches in dma_sync_*for_device
microblaze: dma-mapping: skip extra DMA flushes
powerpc: dma-mapping: split out cache operation logic
powerpc: dma-mapping: minimize for_cpu flushing
powerpc: dma-mapping: always clean cache in _for_device() op
riscv: dma-mapping: only invalidate after DMA, not flush
riscv: dma-mapping: skip invalidation before bidirectional DMA
csky: dma-mapping: skip invalidating before DMA from device
mips: dma-mapping: skip invalidating before bidirectional DMA
mips: dma-mapping: split out cache operation logic
arc: dma-mapping: skip invalidating before bidirectional DMA
parisc: dma-mapping: use regular flush/invalidate ops
ARM: dma-mapping: always invalidate WT caches before DMA
ARM: dma-mapping: bring back dmac_{clean,inv}_range
ARM: dma-mapping: use arch_sync_dma_for_{device,cpu}() internally
ARM: drop SMP support for ARM11MPCore
ARM: dma-mapping: use generic form of arch_sync_dma_* helpers
ARM: dma-mapping: split out arch_dma_mark_clean() helper
dma-mapping: replace custom code with generic implementation
arch/arc/mm/dma.c | 66 ++------
arch/arm/Kconfig | 4 +
arch/arm/include/asm/cacheflush.h | 21 +++
arch/arm/include/asm/glue-cache.h | 4 +
arch/arm/mach-oxnas/Kconfig | 4 -
arch/arm/mach-oxnas/Makefile | 1 -
arch/arm/mach-oxnas/headsmp.S | 23 ---
arch/arm/mach-oxnas/platsmp.c | 96 -----------
arch/arm/mach-versatile/platsmp-realview.c | 4 -
arch/arm/mm/Kconfig | 19 ---
arch/arm/mm/cache-fa.S | 4 +-
arch/arm/mm/cache-nop.S | 6 +
arch/arm/mm/cache-v4.S | 13 +-
arch/arm/mm/cache-v4wb.S | 4 +-
arch/arm/mm/cache-v4wt.S | 22 ++-
arch/arm/mm/cache-v6.S | 35 +---
arch/arm/mm/cache-v7.S | 6 +-
arch/arm/mm/cache-v7m.S | 4 +-
arch/arm/mm/dma-mapping-nommu.c | 36 ++--
arch/arm/mm/dma-mapping.c | 181 ++++++++++-----------
arch/arm/mm/proc-arm1020.S | 4 +-
arch/arm/mm/proc-arm1020e.S | 4 +-
arch/arm/mm/proc-arm1022.S | 4 +-
arch/arm/mm/proc-arm1026.S | 4 +-
arch/arm/mm/proc-arm920.S | 4 +-
arch/arm/mm/proc-arm922.S | 4 +-
arch/arm/mm/proc-arm925.S | 4 +-
arch/arm/mm/proc-arm926.S | 4 +-
arch/arm/mm/proc-arm940.S | 4 +-
arch/arm/mm/proc-arm946.S | 4 +-
arch/arm/mm/proc-feroceon.S | 8 +-
arch/arm/mm/proc-macros.S | 2 +
arch/arm/mm/proc-mohawk.S | 4 +-
arch/arm/mm/proc-xsc3.S | 4 +-
arch/arm/mm/proc-xscale.S | 6 +-
arch/arm64/mm/dma-mapping.c | 28 ++--
arch/csky/mm/dma-mapping.c | 46 +++---
arch/hexagon/kernel/dma.c | 44 ++---
arch/m68k/kernel/dma.c | 43 +++--
arch/microblaze/kernel/dma.c | 38 ++---
arch/mips/mm/dma-noncoherent.c | 75 +++------
arch/nios2/mm/dma-mapping.c | 57 +++----
arch/openrisc/kernel/dma.c | 62 ++++---
arch/parisc/include/asm/cacheflush.h | 6 +-
arch/parisc/kernel/pci-dma.c | 33 +++-
arch/powerpc/mm/dma-noncoherent.c | 76 +++++----
arch/riscv/mm/dma-noncoherent.c | 51 +++---
arch/sh/kernel/dma-coherent.c | 43 +++--
arch/sparc/Kconfig | 2 +-
arch/sparc/kernel/ioport.c | 38 +++--
arch/xtensa/Kconfig | 1 -
arch/xtensa/include/asm/cacheflush.h | 6 +-
arch/xtensa/kernel/pci-dma.c | 47 +++---
include/linux/dma-sync.h | 107 ++++++++++++
54 files changed, 721 insertions(+), 699 deletions(-)
delete mode 100644 arch/arm/mach-oxnas/headsmp.S
delete mode 100644 arch/arm/mach-oxnas/platsmp.c
create mode 100644 include/linux/dma-sync.h
--
2.39.2
Cc: Vineet Gupta <vgupta@...nel.org>
Cc: Russell King <linux@...linux.org.uk>
Cc: Neil Armstrong <neil.armstrong@...aro.org>
Cc: Linus Walleij <linus.walleij@...aro.org>
Cc: Catalin Marinas <catalin.marinas@....com>
Cc: Will Deacon <will@...nel.org>
Cc: Guo Ren <guoren@...nel.org>
Cc: Brian Cain <bcain@...cinc.com>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Michal Simek <monstr@...str.eu>
Cc: Thomas Bogendoerfer <tsbogend@...ha.franken.de>
Cc: Dinh Nguyen <dinguyen@...nel.org>
Cc: Stafford Horne <shorne@...il.com>
Cc: Helge Deller <deller@....de>
Cc: Michael Ellerman <mpe@...erman.id.au>
Cc: Christophe Leroy <christophe.leroy@...roup.eu>
Cc: Paul Walmsley <paul.walmsley@...ive.com>
Cc: Palmer Dabbelt <palmer@...belt.com>
Cc: Rich Felker <dalias@...c.org>
Cc: John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
Cc: "David S. Miller" <davem@...emloft.net>
Cc: Max Filippov <jcmvbkbc@...il.com>
Cc: Christoph Hellwig <hch@....de>
Cc: Robin Murphy <robin.murphy@....com>
Cc: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Cc: Conor Dooley <conor.dooley@...rochip.com>
Cc: linux-snps-arc@...ts.infradead.org
Cc: linux-kernel@...r.kernel.org
Cc: linux-arm-kernel@...ts.infradead.org
Cc: linux-oxnas@...ups.io
Cc: linux-csky@...r.kernel.org
Cc: linux-hexagon@...r.kernel.org
Cc: linux-m68k@...ts.linux-m68k.org
Cc: linux-mips@...r.kernel.org
Cc: linux-openrisc@...r.kernel.org
Cc: linux-parisc@...r.kernel.org
Cc: linuxppc-dev@...ts.ozlabs.org
Cc: linux-riscv@...ts.infradead.org
Cc: linux-sh@...r.kernel.org
Cc: sparclinux@...r.kernel.org
Cc: linux-xtensa@...ux-xtensa.org
Powered by blists - more mailing lists