linux-kernel - RE: [PATCH v4 07/12] Introduce cpu_dcache_is

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]
Message-ID: <65c54d06e2258_afa429450@dwillia2-xfh.jf.intel.com.notmuch>
Date: Thu, 8 Feb 2024 13:52:06 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Dan Williams
	<dan.j.williams@...el.com>, Arnd Bergmann <arnd@...db.de>, Dave Chinner
	<david@...morbit.com>
CC: <linux-kernel@...r.kernel.org>, Mathieu Desnoyers
	<mathieu.desnoyers@...icios.com>, Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>, Vishal Verma
	<vishal.l.verma@...el.com>, Dave Jiang <dave.jiang@...el.com>, Matthew Wilcox
	<willy@...radead.org>, Russell King <linux@...linux.org.uk>,
	<linux-arch@...r.kernel.org>, <linux-cxl@...r.kernel.org>,
	<linux-fsdevel@...r.kernel.org>, <linux-mm@...ck.org>,
	<linux-xfs@...r.kernel.org>, <dm-devel@...ts.linux.dev>,
	<nvdimm@...ts.linux.dev>, <linux-s390@...r.kernel.org>
Subject: RE: [PATCH v4 07/12] Introduce cpu_dcache_is_aliasing() across all
 architectures

Mathieu Desnoyers wrote:
> Introduce a generic way to query whether the data cache is virtually
> aliased on all architectures. Its purpose is to ensure that subsystems
> which are incompatible with virtually aliased data caches (e.g. FS_DAX)
> can reliably query this.
> 
> For data cache aliasing, there are three scenarios dependending on the
> architecture. Here is a breakdown based on my understanding:
> 
> A) The data cache is always aliasing:
> 
> * arc
> * csky
> * m68k (note: shared memory mappings are incoherent ? SHMLBA is missing there.)
> * sh
> * parisc
> 
> B) The data cache aliasing is statically known or depends on querying CPU
>    state at runtime:
> 
> * arm (cache_is_vivt() || cache_is_vipt_aliasing())
> * mips (cpu_has_dc_aliases)
> * nios2 (NIOS2_DCACHE_SIZE > PAGE_SIZE)
> * sparc32 (vac_cache_size > PAGE_SIZE)
> * sparc64 (L1DCACHE_SIZE > PAGE_SIZE)
> * xtensa (DCACHE_WAY_SIZE > PAGE_SIZE)
> 
> C) The data cache is never aliasing:
> 
> * alpha
> * arm64 (aarch64)
> * hexagon
> * loongarch (but with incoherent write buffers, which are disabled since
>              commit d23b7795 ("LoongArch: Change SHMLBA from SZ_64K to PAGE_SIZE"))
> * microblaze
> * openrisc
> * powerpc
> * riscv
> * s390
> * um
> * x86
> 
> Require architectures in A) and B) to select ARCH_HAS_CPU_CACHE_ALIASING and
> implement "cpu_dcache_is_aliasing()".
> 
> Architectures in C) don't select ARCH_HAS_CPU_CACHE_ALIASING, and thus
> cpu_dcache_is_aliasing() simply evaluates to "false".
> 
> Note that this leaves "cpu_icache_is_aliasing()" to be implemented as future
> work. This would be useful to gate features like XIP on architectures
> which have aliasing CPU dcache-icache but not CPU dcache-dcache.
> 
> Use "cpu_dcache" and "cpu_cache" rather than just "dcache" and "cache"
> to clarify that we really mean "CPU data cache" and "CPU cache" to
> eliminate any possible confusion with VFS "dentry cache" and "page
> cache".
> 
> Link: https://lore.kernel.org/lkml/20030910210416.GA24258@mail.jlokier.co.uk/
> Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing caches")
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> Cc: Dan Williams <dan.j.williams@...el.com>
> Cc: Vishal Verma <vishal.l.verma@...el.com>
> Cc: Dave Jiang <dave.jiang@...el.com>
> Cc: Matthew Wilcox <willy@...radead.org>
> Cc: Arnd Bergmann <arnd@...db.de>
> Cc: Russell King <linux@...linux.org.uk>
> Cc: linux-arch@...r.kernel.org
> Cc: linux-cxl@...r.kernel.org
> Cc: linux-fsdevel@...r.kernel.org
> Cc: linux-mm@...ck.org
> Cc: linux-xfs@...r.kernel.org
> Cc: dm-devel@...ts.linux.dev
> Cc: nvdimm@...ts.linux.dev
> ---
>  arch/arc/Kconfig                    |  1 +
>  arch/arc/include/asm/cachetype.h    |  9 +++++++++
>  arch/arm/Kconfig                    |  1 +
>  arch/arm/include/asm/cachetype.h    |  2 ++
>  arch/csky/Kconfig                   |  1 +
>  arch/csky/include/asm/cachetype.h   |  9 +++++++++
>  arch/m68k/Kconfig                   |  1 +
>  arch/m68k/include/asm/cachetype.h   |  9 +++++++++
>  arch/mips/Kconfig                   |  1 +
>  arch/mips/include/asm/cachetype.h   |  9 +++++++++
>  arch/nios2/Kconfig                  |  1 +
>  arch/nios2/include/asm/cachetype.h  | 10 ++++++++++
>  arch/parisc/Kconfig                 |  1 +
>  arch/parisc/include/asm/cachetype.h |  9 +++++++++
>  arch/sh/Kconfig                     |  1 +
>  arch/sh/include/asm/cachetype.h     |  9 +++++++++
>  arch/sparc/Kconfig                  |  1 +
>  arch/sparc/include/asm/cachetype.h  | 14 ++++++++++++++
>  arch/xtensa/Kconfig                 |  1 +
>  arch/xtensa/include/asm/cachetype.h | 10 ++++++++++
>  include/linux/cacheinfo.h           |  6 ++++++
>  mm/Kconfig                          |  6 ++++++
>  22 files changed, 112 insertions(+)
>  create mode 100644 arch/arc/include/asm/cachetype.h
>  create mode 100644 arch/csky/include/asm/cachetype.h
>  create mode 100644 arch/m68k/include/asm/cachetype.h
>  create mode 100644 arch/mips/include/asm/cachetype.h
>  create mode 100644 arch/nios2/include/asm/cachetype.h
>  create mode 100644 arch/parisc/include/asm/cachetype.h
>  create mode 100644 arch/sh/include/asm/cachetype.h
>  create mode 100644 arch/sparc/include/asm/cachetype.h
>  create mode 100644 arch/xtensa/include/asm/cachetype.h
> 
[..]
> diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h
> index d504eb4b49ab..2cb15fe4fe12 100644
> --- a/include/linux/cacheinfo.h
> +++ b/include/linux/cacheinfo.h
> @@ -138,4 +138,10 @@ static inline int get_cpu_cacheinfo_id(int cpu, int level)
>  #define use_arch_cache_info()	(false)
>  #endif
>  
> +#ifndef CONFIG_ARCH_HAS_CPU_CACHE_ALIASING
> +#define cpu_dcache_is_aliasing()	false
> +#else
> +#include <asm/cachetype.h>
> +#endif
> +
>  #endif /* _LINUX_CACHEINFO_H */
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 57cd378c73d6..db09c9ad15c9 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -1016,6 +1016,12 @@ config IDLE_PAGE_TRACKING
>  	  See Documentation/admin-guide/mm/idle_page_tracking.rst for
>  	  more details.
>  
> +# Architectures which implement cpu_dcache_is_aliasing() to query
> +# whether the data caches are aliased (VIVT or VIPT with dcache
> +# aliasing) need to select this.
> +config ARCH_HAS_CPU_CACHE_ALIASING
> +	bool
> +
>  config ARCH_HAS_CACHE_LINE_SIZE
>  	bool

I can't speak to the specific arch changes, but the generic support
above looks ok.

If you get any pushback on the per arch changes then maybe this could be
split into a patch that simply does the coarse grained select of
CONFIG_ARCH_HAS_CPU_CACHE_ALIASING for ARM, MIPS, and SPARC. Then,
follow-on with patches per-arch to do the more fine grained option.

Certainly Andrew's tree is great for simultaneous cross arch changes
like this.