[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65bab567665f3_37ad2943c@dwillia2-xfh.jf.intel.com.notmuch>
Date: Wed, 31 Jan 2024 13:02:31 -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>, <linux-mm@...ck.org>,
<linux-arch@...r.kernel.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>, <nvdimm@...ts.linux.dev>,
<linux-cxl@...r.kernel.org>, <linux-fsdevel@...r.kernel.org>,
<dm-devel@...ts.linux.dev>
Subject: RE: [RFC PATCH v3 2/4] dax: Check for data cache aliasing at runtime
Mathieu Desnoyers wrote:
> Replace the following fs/Kconfig:FS_DAX dependency:
>
> depends on !(ARM || MIPS || SPARC)
>
> By a runtime check within alloc_dax().
>
> This is done in preparation for its use by each filesystem supporting
> the "dax" mount option to validate whether DAX is indeed supported.
>
> This is done in preparation for using cpu_dcache_is_aliasing() in a
> following change which will properly support architectures which detect
> data cache aliasing at runtime.
>
> 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
> Cc: dm-devel@...ts.linux.dev
> ---
> drivers/dax/super.c | 6 ++++++
> fs/Kconfig | 1 -
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> index 0da9232ea175..e9f397b8a5a3 100644
> --- a/drivers/dax/super.c
> +++ b/drivers/dax/super.c
> @@ -445,6 +445,12 @@ struct dax_device *alloc_dax(void *private, const struct dax_operations *ops)
> dev_t devt;
> int minor;
>
> + /* Unavailable on architectures with virtually aliased data caches. */
> + if (IS_ENABLED(CONFIG_ARM) ||
> + IS_ENABLED(CONFIG_MIPS) ||
> + IS_ENABLED(CONFIG_SPARC))
> + return NULL;
This function returns ERR_PTR(), not NULL on failure.
..and I notice this mistake is also made in include/linux/dax.h in the
CONFIG_DAX=n case. That function also mentions:
static inline struct dax_device *alloc_dax(void *private,
const struct dax_operations *ops)
{
/*
* Callers should check IS_ENABLED(CONFIG_DAX) to know if this
* NULL is an error or expected.
*/
return NULL;
}
..and none of the callers validate the result, but now runtime
validation is necessary. I.e. it is not enough to check
IS_ENABLED(CONFIG_DAX) it also needs to check cpu_dcache_is_aliasing().
With that, there are a few more fixup places needed, pmem_attach_disk(),
dcssblk_add_store(), and virtio_fs_setup_dax().
Powered by blists - more mailing lists