[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zbm2eS/AMlmhm8EW@dread.disaster.area>
Date: Wed, 31 Jan 2024 13:54:49 +1100
From: Dave Chinner <david@...morbit.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Dan Williams <dan.j.williams@...el.com>,
Vishal Verma <vishal.l.verma@...el.com>,
Dave Jiang <dave.jiang@...el.com>, linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>, linux-mm@...ck.org,
linux-arch@...r.kernel.org, Matthew Wilcox <willy@...radead.org>,
Arnd Bergmann <arnd@...db.de>, Russell King <linux@...linux.org.uk>,
nvdimm@...ts.linux.dev, linux-cxl@...r.kernel.org,
linux-fsdevel@...r.kernel.org
Subject: Re: [RFC PATCH v2 8/8] dax: Fix incorrect list of dcache aliasing
architectures
On Tue, Jan 30, 2024 at 11:52:55AM -0500, Mathieu Desnoyers wrote:
> commit d92576f1167c ("dax: does not work correctly with virtual aliasing caches")
> prevents DAX from building on architectures with virtually aliased
> dcache with:
>
> depends on !(ARM || MIPS || SPARC)
>
> This check is too broad (e.g. recent ARMv7 don't have virtually aliased
> dcaches), and also misses many other architectures with virtually
> aliased dcache.
>
> This is a regression introduced in the v5.13 Linux kernel where the
> dax mount option is removed for 32-bit ARMv7 boards which have no dcache
> aliasing, and therefore should work fine with FS_DAX.
>
> This was turned into the following implementation of dax_is_supported()
> by a preparatory change:
>
> return !IS_ENABLED(CONFIG_ARM) &&
> !IS_ENABLED(CONFIG_MIPS) &&
> !IS_ENABLED(CONFIG_SPARC);
>
> Use dcache_is_aliasing() instead to figure out whether the environment
> has aliasing dcaches.
>
> 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: linux-mm@...ck.org
> Cc: linux-arch@...r.kernel.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: nvdimm@...ts.linux.dev
> Cc: linux-cxl@...r.kernel.org
> Cc: linux-fsdevel@...r.kernel.org
> ---
> include/linux/dax.h | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/dax.h b/include/linux/dax.h
> index cfc8cd4a3eae..f59e604662e4 100644
> --- a/include/linux/dax.h
> +++ b/include/linux/dax.h
> @@ -5,6 +5,7 @@
> #include <linux/fs.h>
> #include <linux/mm.h>
> #include <linux/radix-tree.h>
> +#include <linux/cacheinfo.h>
>
> typedef unsigned long dax_entry_t;
>
> @@ -80,9 +81,7 @@ static inline bool daxdev_mapping_supported(struct vm_area_struct *vma,
> }
> static inline bool dax_is_supported(void)
> {
> - return !IS_ENABLED(CONFIG_ARM) &&
> - !IS_ENABLED(CONFIG_MIPS) &&
> - !IS_ENABLED(CONFIG_SPARC);
> + return !dcache_is_aliasing();
Yeah, if this is just a one liner should go into
fs_dax_get_by_bdev(), similar to the blk_queue_dax() check at the
start of the function.
I also noticed that device mapper uses fs_dax_get_by_bdev() to
determine if it can support DAX, but this patch set does not address
that case. Hence it really seems to me like fs_dax_get_by_bdev() is
the right place to put this check.
-Dave.
--
Dave Chinner
david@...morbit.com
Powered by blists - more mailing lists