From: Dan Williams <dan.j.williams@intel.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
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: RE: [PATCH v4 06/12] dax: Check for data cache aliasing at runtime
Date: Thu, 8 Feb 2024 13:39:31 -0800 [thread overview]
Message-ID: <65c54a13c52e_afa429444@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <20240208184913.484340-7-mathieu.desnoyers@efficios.com>
Mathieu Desnoyers wrote:
> Replace the following fs/Kconfig:FS_DAX dependency:
>
> depends on !(ARM || MIPS || SPARC)
>
> By a runtime check within alloc_dax(). This runtime check returns
> ERR_PTR(-EOPNOTSUPP) if the @ops parameter is non-NULL (which means
> the kernel is using an aliased mapping) on an architecture which
> has data cache aliasing.
>
> Change the return value from NULL to PTR_ERR(-EOPNOTSUPP) for
> CONFIG_DAX=n for consistency.
>
> 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@efficios.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Vishal Verma <vishal.l.verma@intel.com>
> Cc: Dave Jiang <dave.jiang@intel.com>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> 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
> ---
> drivers/dax/super.c | 15 +++++++++++++++
> fs/Kconfig | 1 -
> include/linux/dax.h | 6 +-----
> 3 files changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> index 0da9232ea175..ce5bffa86bba 100644
> --- a/drivers/dax/super.c
> +++ b/drivers/dax/super.c
> @@ -319,6 +319,11 @@ EXPORT_SYMBOL_GPL(dax_alive);
> * that any fault handlers or operations that might have seen
> * dax_alive(), have completed. Any operations that start after
> * synchronize_srcu() has run will abort upon seeing !dax_alive().
> + *
> + * Note, because alloc_dax() returns an ERR_PTR() on error, callers
> + * typically store its result into a local variable in order to check
> + * the result. Therefore, care must be taken to populate the struct
> + * device dax_dev field make sure the dax_dev is not leaked.
> */
> void kill_dax(struct dax_device *dax_dev)
> {
> @@ -445,6 +450,16 @@ 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,
> + * except for device-dax (NULL operations pointer), which does
> + * not use aliased mappings from the kernel.
> + */
> + if (ops && (IS_ENABLED(CONFIG_ARM) ||
> + IS_ENABLED(CONFIG_MIPS) ||
> + IS_ENABLED(CONFIG_SPARC)))
> + return ERR_PTR(-EOPNOTSUPP);
> +
> if (WARN_ON_ONCE(ops && !ops->zero_page_range))
> return ERR_PTR(-EINVAL);
>
> diff --git a/fs/Kconfig b/fs/Kconfig
> index 42837617a55b..e5efdb3b276b 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -56,7 +56,6 @@ endif # BLOCK
> config FS_DAX
> bool "File system based Direct Access (DAX) support"
> depends on MMU
> - depends on !(ARM || MIPS || SPARC)
> depends on ZONE_DEVICE || FS_DAX_LIMITED
> select FS_IOMAP
> select DAX
> diff --git a/include/linux/dax.h b/include/linux/dax.h
> index b463502b16e1..df2d52b8a245 100644
> --- a/include/linux/dax.h
> +++ b/include/linux/dax.h
> @@ -86,11 +86,7 @@ static inline void *dax_holder(struct dax_device *dax_dev)
> 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;
> + return ERR_PTR(-EOPNOTSUPP);
> }
So per other feedback on earlier patches, I think this hunk deserves to
be moved to its own patch earlier in the series as a standalone fixup.
Rest of this patch looks good to me.
next prev parent reply other threads:[~2024-02-08 21:39 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-08 18:49 [PATCH v4 00/12] Introduce cpu_dcache_is_aliasing() to fix DAX regression Mathieu Desnoyers
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 [this message]
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=65c54a13c52e_afa429444@dwillia2-xfh.jf.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--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=mathieu.desnoyers@efficios.com \
--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 NNTP newsgroup(s).