From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Dan Williams <dan.j.williams@intel.com>,
Arnd Bergmann <arnd@arndb.de>, Dave Chinner <david@fromorbit.com>
Cc: linux-kernel@vger.kernel.org,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Vishal Verma <vishal.l.verma@intel.com>,
Dave Jiang <dave.jiang@intel.com>,
Matthew Wilcox <willy@infradead.org>,
Russell King <linux@armlinux.org.uk>,
linux-arch@vger.kernel.org, linux-cxl@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-xfs@vger.kernel.org, dm-devel@lists.linux.dev,
nvdimm@lists.linux.dev, linux-s390@vger.kernel.org
Subject: [PATCH v4 00/12] Introduce cpu_dcache_is_aliasing() to fix DAX regression
Date: Thu, 8 Feb 2024 13:49:01 -0500 [thread overview]
Message-ID: <20240208184913.484340-1-mathieu.desnoyers@efficios.com> (raw)
This commit introduced in v4.0 prevents building FS_DAX on 32-bit ARM,
even on ARMv7 which does not have virtually aliased data caches:
commit d92576f1167c ("dax: does not work correctly with virtual aliasing caches")
It used to work fine before: I have customers using DAX over pmem on
ARMv7, but this regression will likely prevent them from upgrading their
kernel.
The root of the issue here is the fact that DAX was never designed to
handle virtually aliasing data caches (VIVT and VIPT with aliasing data
cache). It touches the pages through their linear mapping, which is not
consistent with the userspace mappings with virtually aliasing data
caches.
This patch series introduces cpu_dcache_is_aliasing() with the new
Kconfig option ARCH_HAS_CPU_CACHE_ALIASING and implements it for all
architectures. The implementation of cpu_dcache_is_aliasing() is either
evaluated to a constant at compile-time or a runtime check, which is
what is needed on ARM.
With this we can basically narrow down the list of architectures which
are unsupported by DAX to those which are really affected.
Testing done so far:
- Compile allyesconfig on x86-64,
- Compile allyesconfig on x86-64, with FS_DAX=n.
- Compile allyesconfig on x86-64, with DAX=n.
- Boot test after modifying alloc_dax() to force returning -EOPNOTSUPP
even on x86-64, thus simulating the behavior expected on an
architecture with data cache aliasing.
There are many more axes to test however. I would welcome Tested-by for:
- affected architectures,
- affected drivers,
- affected filesytems.
Thanks,
Mathieu
Changes since v3:
- Fix a leak on dax_add_host() failure in nvdimm/pmem.
- Split the series into a bissectable sequence of changes.
- Ensure that device-dax use-cases still works on data cache
aliasing architectures.
Changes since v2:
- Move DAX supported runtime check to alloc_dax(),
- Modify DM to handle alloc_dax() error as non-fatal,
- Remove all filesystem modifications, since the check is now done by
alloc_dax(),
- rename "dcache" and "cache" to "cpu dcache" and "cpu cache" to
eliminate confusion with VFS terminology.
Changes since v1:
- The order of the series was completely changed based on the
feedback received on v1,
- cache_is_aliasing() is renamed to dcache_is_aliasing(),
- ARCH_HAS_CACHE_ALIASING_DYNAMIC is gone,
- dcache_is_aliasing() vs ARCH_HAS_CACHE_ALIASING relationship is
simplified,
- the dax_is_supported() check was moved to its rightful place in all
filesystems.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arch@vger.kernel.org
Cc: linux-cxl@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: linux-xfs@vger.kernel.org
Cc: dm-devel@lists.linux.dev
Cc: nvdimm@lists.linux.dev
Cc: linux-s390@vger.kernel.org
Mathieu Desnoyers (12):
nvdimm/pmem: Fix leak on dax_add_host() failure
nvdimm/pmem: Treat alloc_dax() -EOPNOTSUPP failure as non-fatal
dm: Treat alloc_dax() -EOPNOTSUPP failure as non-fatal
dcssblk: Handle alloc_dax() -EOPNOTSUPP failure
virtio: Treat alloc_dax() -EOPNOTSUPP failure as non-fatal
dax: Check for data cache aliasing at runtime
Introduce cpu_dcache_is_aliasing() across all architectures
dax: Fix incorrect list of data cache aliasing architectures
nvdimm/pmem: Cleanup alloc_dax() error handling
dm: Cleanup alloc_dax() error handling
dcssblk: Cleanup alloc_dax() error handling
virtio: Cleanup alloc_dax() error handling
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 ++++++++++
drivers/dax/super.c | 14 ++++++++++++++
drivers/md/dm.c | 17 +++++++++--------
drivers/nvdimm/pmem.c | 23 ++++++++++++-----------
drivers/s390/block/dcssblk.c | 11 ++++++-----
fs/Kconfig | 1 -
fs/fuse/virtio_fs.c | 15 +++++++++++----
include/linux/cacheinfo.h | 6 ++++++
include/linux/dax.h | 6 +-----
mm/Kconfig | 6 ++++++
29 files changed, 165 insertions(+), 34 deletions(-)
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
--
2.39.2
next reply other threads:[~2024-02-08 18:49 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-08 18:49 Mathieu Desnoyers [this message]
2024-02-08 18:49 ` [PATCH v4 01/12] nvdimm/pmem: Fix leak on dax_add_host() failure Mathieu Desnoyers
2024-02-08 21:21 ` Andrew Morton
2024-02-08 22:04 ` Mathieu Desnoyers
2024-02-08 22:12 ` Andrew Morton
2024-02-08 22:16 ` Mathieu Desnoyers
2024-02-08 21:28 ` Dan Williams
2024-02-08 18:49 ` [PATCH v4 02/12] nvdimm/pmem: Treat alloc_dax() -EOPNOTSUPP failure as non-fatal Mathieu Desnoyers
2024-02-08 21:32 ` Dan Williams
2024-02-08 22:07 ` Mathieu Desnoyers
2024-02-08 18:49 ` [PATCH v4 03/12] dm: " Mathieu Desnoyers
2024-02-08 21:34 ` Dan Williams
2024-02-08 22:07 ` Mathieu Desnoyers
2024-02-08 18:49 ` [PATCH v4 04/12] dcssblk: Handle alloc_dax() -EOPNOTSUPP failure Mathieu Desnoyers
2024-02-08 21:36 ` Dan Williams
2024-02-08 22:08 ` Mathieu Desnoyers
2024-02-08 18:49 ` [PATCH v4 05/12] virtio: Treat alloc_dax() -EOPNOTSUPP failure as non-fatal Mathieu Desnoyers
2024-02-08 21:37 ` Dan Williams
2024-02-08 22:09 ` Mathieu Desnoyers
2024-02-08 18:49 ` [PATCH v4 06/12] dax: Check for data cache aliasing at runtime Mathieu Desnoyers
2024-02-08 21:39 ` Dan Williams
2024-02-08 22:10 ` Mathieu Desnoyers
2024-02-08 22:37 ` Dan Williams
2024-02-08 22:42 ` Mathieu Desnoyers
2024-02-09 1:01 ` Dan Williams
2024-02-08 18:49 ` [PATCH v4 07/12] Introduce cpu_dcache_is_aliasing() across all architectures Mathieu Desnoyers
2024-02-08 21:52 ` Dan Williams
2024-02-08 18:49 ` [PATCH v4 08/12] dax: Fix incorrect list of data cache aliasing architectures Mathieu Desnoyers
2024-02-08 21:52 ` Dan Williams
2024-02-08 18:49 ` [PATCH v4 09/12] nvdimm/pmem: Cleanup alloc_dax() error handling Mathieu Desnoyers
2024-02-08 21:55 ` Dan Williams
2024-02-08 22:12 ` Mathieu Desnoyers
2024-02-08 18:49 ` [PATCH v4 10/12] dm: " Mathieu Desnoyers
2024-02-08 18:49 ` [PATCH v4 11/12] dcssblk: " Mathieu Desnoyers
2024-02-08 18:49 ` [PATCH v4 12/12] virtio: " Mathieu Desnoyers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240208184913.484340-1-mathieu.desnoyers@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=david@fromorbit.com \
--cc=dm-devel@lists.linux.dev \
--cc=linux-arch@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=nvdimm@lists.linux.dev \
--cc=torvalds@linux-foundation.org \
--cc=vishal.l.verma@intel.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).