Received-SPF: pass (google.com: domain of linux-kernel+bounces-45703-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Tue, 30 Jan 2024 19:13:03 -0800
From: Dan Williams <dan.j.williams@intel.com>
To: Dave Chinner <david@fromorbit.com>, Mathieu Desnoyers
	<mathieu.desnoyers@efficios.com>
CC: Dan Williams <dan.j.williams@intel.com>, Vishal Verma
	<vishal.l.verma@intel.com>, Dave Jiang <dave.jiang@intel.com>,
	<linux-kernel@vger.kernel.org>, Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>, <linux-mm@kvack.org>,
	<linux-arch@vger.kernel.org>, Matthew Wilcox <willy@infradead.org>, "Arnd
 Bergmann" <arnd@arndb.de>, Russell King <linux@armlinux.org.uk>,
	<nvdimm@lists.linux.dev>, <linux-cxl@vger.kernel.org>,
	<linux-fsdevel@vger.kernel.org>
Subject: Re: [RFC PATCH v2 8/8] dax: Fix incorrect list of dcache aliasing
 architectures
Message-ID: <65b9babf6b3de_5a9dd294de@dwillia2-mobl3.amr.corp.intel.com.notmuch>
References: <20240130165255.212591-1-mathieu.desnoyers@efficios.com>
 <20240130165255.212591-9-mathieu.desnoyers@efficios.com>
 <Zbm2eS/AMlmhm8EW@dread.disaster.area>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Zbm2eS/AMlmhm8EW@dread.disaster.area>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?lfVC0cp+HqyTzLtRl0v/bnPNhjx7hUzehDtArC0jzgrlwYAPRlcXy1uioBIP?=
 =?us-ascii?Q?2fZqP6kOq2zQ1zVHZDBBmVORwhsGt4nEctGjtOrwWsevzeC8IH5K31xgFlzG?=
 =?us-ascii?Q?tO0ionj+nLdExCkmJM+X5cvJWHP7DQbMqqQfY7JI53nYXZ6/g8EUa9ZDCxgr?=
 =?us-ascii?Q?UNLX6m+6EETff4ETSJNZOjsixxpptW748gzBsvbKm3LCu0uagpRctzUTyrt/?=
 =?us-ascii?Q?OVedPU7MsGKkhytwJivbupkp5+/6fBREUQm8CPKTfsR60n7wF+fV5gGuxFPA?=
 =?us-ascii?Q?nPSfOYVC4NUu2h8yMpBelUp09siyhhq7k0dqZZKEX+Q0om8mn8FMzsz7Cold?=
 =?us-ascii?Q?t8kQbm319BFkHqkGq4VwqEjAc0Vsyj5JerDjY14U5y85xDQ+3fpJBIU4flTO?=
 =?us-ascii?Q?4ATQfGPnW01TfEJmn8a2LWt7ww1QC9tP27Tb8GP9DzpMNIHqpiRAjPF9zJTi?=
 =?us-ascii?Q?rWfwvSFK5yyCsZtw3reN8wl/IdGqlp2D0SLVkt6o8ERmU5lVL9vlA6eiRBf8?=
 =?us-ascii?Q?PCrdfsLT5qtIgfdo1VFj7LboH+uLCwImdWJHFKjpQi34hN8UK7by5jmwtVJ7?=
 =?us-ascii?Q?PgpoRcJ6ziL+OVnURYRzfF0H3rhGmoWKgXKfUuGfMHqrDUgaP/ATRpGkDDqs?=
 =?us-ascii?Q?i1Bg+0gGOz8GnjegqtFmQT7VDSfvBO9YEBTmuKTRaG7schJCBaJAYrWiqYjH?=
 =?us-ascii?Q?L34px405fAP4GrkWDA7nEsB06sbMf7uU/CUFAwapr2hBQbRslUX9+nWTqAUJ?=
 =?us-ascii?Q?zwYp+WE4XmByJi9kekD52Aw1e7ARcIjp6Oed0KuvANDe1jz4JtdE+D3CWaTg?=
 =?us-ascii?Q?P/rYrHvBF4bXob9ZB41HMZrVlBQptw4hflvT+yaJxygkB2xirDYoaHJm+msD?=
 =?us-ascii?Q?BHMsBMwG58r3H2dPsiUVQtO7zcEg9E738MX6UxN+d28vPvbinKDb08r3CU4F?=
 =?us-ascii?Q?3E5jVgX6FLsONOmccEdlulLIcyrZxldEiZXuCjgXtl4M/KRuQWjxfSQO7ZlP?=
 =?us-ascii?Q?1PjXnlQAp9ubSHZKEc0rR45I3bTz2fk9XcdddoVXKohlNbvCZv3xsllTYSb2?=
 =?us-ascii?Q?hrERY4GxWrOqISUDmjiGsDCQata4bdNPi04wyf2C4rh29nB4t4bEfg7xMfV0?=
 =?us-ascii?Q?OuNNY9Qh4gCpyE0GlYnWBgABZXbjfSfyDlaRppq1XYhBtOOySAhm+LyYkI3m?=
 =?us-ascii?Q?n+6X0RzrCMZb3rDqremId+5VGr3PfkJPI9/qfmfAej7vTKw4yqfobosoHOyR?=
 =?us-ascii?Q?JgIjSM8gjMXGVO7Lyw3FTtUI0eDsuqfSIC45icUg7zo6tldVvtO+sCwaDO/g?=
 =?us-ascii?Q?Kmjj2naiYpUkLGXe8Ai5PEv335nJUY+lbmAmPJ26LZepoop/mYR6eDNW2Cot?=
 =?us-ascii?Q?SRNeg+OHof3P7Lr5biOjJzwG0Ui+3kICSP1dgHPuY9aif0Z51eHkVmeFQIN4?=
 =?us-ascii?Q?p6nEIlCwGNefRu+Cl3PHWK9TshiPaQsikF/Uud7bbD6HmKgMl2kUUKG99z0I?=
 =?us-ascii?Q?FU+KVAMeaCv3UCsNza/0aGtKUe14RQ0JnFFeCsGblv6O4z38plrWFSyV/au+?=
 =?us-ascii?Q?2SqMXJGFQvPDjmAPbXQLbjt5mo96KHkQOF3TCpebDBAfwi7PboGKbkwlWhB4?=
 =?us-ascii?Q?6w=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: e100dab7-843d-4c85-14a5-08dc220a8b4a
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2024 03:13:06.2790
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: yMK7cnopuTv0VGY9rpz0VjJMhExERLGu+8Fg+Fn8a8IrbDzNculJ1Prdf6u4ZoAyamJiDWPlhm0ov3agtAmNgjW/KaNDoCQ0QrkrRvRRfKc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB6407
X-OriginatorOrg: intel.com

Dave Chinner wrote:
> 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@efficios.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Linus Torvalds <torvalds@linux-foundation.org>
> > Cc: linux-mm@kvack.org
> > Cc: linux-arch@vger.kernel.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: nvdimm@lists.linux.dev
> > Cc: linux-cxl@vger.kernel.org
> > Cc: linux-fsdevel@vger.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.

Oh, good catch. Yes, I agree this can definitely be pushed down, but
then I think it should be pushed down all the way to make alloc_dax()
fail. That will need some additional fixups like:

diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 8dcabf84d866..a35e60e62440 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -2126,12 +2126,12 @@ static struct mapped_device *alloc_dev(int minor)
                md->dax_dev = alloc_dax(md, &dm_dax_ops);
                if (IS_ERR(md->dax_dev)) {
                        md->dax_dev = NULL;
-                       goto bad;
+               } else {
+                       set_dax_nocache(md->dax_dev);
+                       set_dax_nomc(md->dax_dev);
+                       if (dax_add_host(md->dax_dev, md->disk))
+                               goto bad;
                }
-               set_dax_nocache(md->dax_dev);
-               set_dax_nomc(md->dax_dev);
-               if (dax_add_host(md->dax_dev, md->disk))
-                       goto bad;
        }
 
        format_dev_t(md->name, MKDEV(_major, minor));

..to make it not fatal to fail to register the dax_dev.