[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65c548ea54127_afa429463@dwillia2-xfh.jf.intel.com.notmuch>
Date: Thu, 8 Feb 2024 13:34:34 -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>, Vishal Verma
<vishal.l.verma@...el.com>, Dave Jiang <dave.jiang@...el.com>, Matthew Wilcox
<willy@...radead.org>, Russell King <linux@...linux.org.uk>,
<linux-arch@...r.kernel.org>, <linux-cxl@...r.kernel.org>,
<linux-fsdevel@...r.kernel.org>, <linux-mm@...ck.org>,
<linux-xfs@...r.kernel.org>, <dm-devel@...ts.linux.dev>,
<nvdimm@...ts.linux.dev>, <linux-s390@...r.kernel.org>, Alasdair Kergon
<agk@...hat.com>, Mike Snitzer <snitzer@...nel.org>, Mikulas Patocka
<mpatocka@...hat.com>
Subject: RE: [PATCH v4 03/12] dm: Treat alloc_dax() -EOPNOTSUPP failure as
non-fatal
Mathieu Desnoyers wrote:
> In preparation for checking whether the architecture has data cache
> aliasing within alloc_dax(), modify the error handling of dm alloc_dev()
> to treat alloc_dax() -EOPNOTSUPP failure as non-fatal.
>
> For the transition, consider that alloc_dax() returning NULL is the
> same as returning -EOPNOTSUPP.
>
> Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing caches")
> Suggested-by: Dan Williams <dan.j.williams@...el.com>
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
> Cc: Alasdair Kergon <agk@...hat.com>
> Cc: Mike Snitzer <snitzer@...nel.org>
> Cc: Mikulas Patocka <mpatocka@...hat.com>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Cc: Linus Torvalds <torvalds@...ux-foundation.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: linux-arch@...r.kernel.org
> Cc: linux-cxl@...r.kernel.org
> Cc: linux-fsdevel@...r.kernel.org
> Cc: linux-mm@...ck.org
> Cc: linux-xfs@...r.kernel.org
> Cc: dm-devel@...ts.linux.dev
> Cc: nvdimm@...ts.linux.dev
> ---
> drivers/md/dm.c | 17 +++++++++--------
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/md/dm.c b/drivers/md/dm.c
> index 23c32cd1f1d8..2fc22cae9089 100644
> --- a/drivers/md/dm.c
> +++ b/drivers/md/dm.c
> @@ -2054,6 +2054,7 @@ static void cleanup_mapped_device(struct mapped_device *md)
> static struct mapped_device *alloc_dev(int minor)
> {
> int r, numa_node_id = dm_get_numa_node();
> + struct dax_device *dax_dev;
> struct mapped_device *md;
> void *old_md;
>
> @@ -2122,15 +2123,15 @@ static struct mapped_device *alloc_dev(int minor)
> md->disk->private_data = md;
> sprintf(md->disk->disk_name, "dm-%d", minor);
>
> - if (IS_ENABLED(CONFIG_FS_DAX)) {
> - md->dax_dev = alloc_dax(md, &dm_dax_ops);
> - if (IS_ERR(md->dax_dev)) {
> - md->dax_dev = NULL;
> + dax_dev = alloc_dax(md, &dm_dax_ops);
> + if (IS_ERR_OR_NULL(dax_dev)) {
Similar feedback as the pmem change, lets not propagate the mistake that
alloc_dax() could return NULL, none of the callers of alloc_dax()
properly handled NULL and it was just luck that none of the use cases
tried to use alloc_dax() in the CONFIG_DAX=n case.
Powered by blists - more mailing lists