linux-kernel - Re: [RFC V2 04/18] dev_dax_iomap: Add dax_operations for use by fs-dax on devdax

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250704134744.00006bcd@huawei.com>
Date: Fri, 4 Jul 2025 13:47:44 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: John Groves <John@...ves.net>
CC: Dan Williams <dan.j.williams@...el.com>, Miklos Szeredi
	<miklos@...redb.hu>, Bernd Schubert <bschubert@....com>, John Groves
	<jgroves@...ron.com>, Jonathan Corbet <corbet@....net>, Vishal Verma
	<vishal.l.verma@...el.com>, Dave Jiang <dave.jiang@...el.com>, "Matthew
 Wilcox" <willy@...radead.org>, Jan Kara <jack@...e.cz>, Alexander Viro
	<viro@...iv.linux.org.uk>, Christian Brauner <brauner@...nel.org>, "Darrick J
 . Wong" <djwong@...nel.org>, Randy Dunlap <rdunlap@...radead.org>, "Jeff
 Layton" <jlayton@...nel.org>, Kent Overstreet <kent.overstreet@...ux.dev>,
	<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<nvdimm@...ts.linux.dev>, <linux-cxl@...r.kernel.org>,
	<linux-fsdevel@...r.kernel.org>, Amir Goldstein <amir73il@...il.com>, "Stefan
 Hajnoczi" <shajnocz@...hat.com>, Joanne Koong <joannelkoong@...il.com>, Josef
 Bacik <josef@...icpanda.com>, Aravind Ramesh <arramesh@...ron.com>, Ajay
 Joshi <ajayjoshi@...ron.com>
Subject: Re: [RFC V2 04/18] dev_dax_iomap: Add dax_operations for use by
 fs-dax on devdax

On Thu,  3 Jul 2025 13:50:18 -0500
John Groves <John@...ves.net> wrote:

> Notes about this commit:
> 
> * These methods are based on pmem_dax_ops from drivers/nvdimm/pmem.c
> 
> * dev_dax_direct_access() is returns the hpa, pfn and kva. The kva was
>   newly stored as dev_dax->virt_addr by dev_dax_probe().
> 
> * The hpa/pfn are used for mmap (dax_iomap_fault()), and the kva is used
>   for read/write (dax_iomap_rw())
> 
> * dev_dax_recovery_write() and dev_dax_zero_page_range() have not been
>   tested yet. I'm looking for suggestions as to how to test those.
> 
> Signed-off-by: John Groves <john@...ves.net>
A few trivial things noticed whilst reading through.

> ---
>  drivers/dax/bus.c | 120 ++++++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 115 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
> index 9d9a4ae7bbc0..61a8d1b3c07a 100644
> --- a/drivers/dax/bus.c
> +++ b/drivers/dax/bus.c
> @@ -7,6 +7,10 @@
>  #include <linux/slab.h>
>  #include <linux/dax.h>
>  #include <linux/io.h>
> +#include <linux/backing-dev.h>
> +#include <linux/pfn_t.h>
> +#include <linux/range.h>
> +#include <linux/uio.h>
>  #include "dax-private.h"
>  #include "bus.h"
>  
> @@ -1441,6 +1445,105 @@ __weak phys_addr_t dax_pgoff_to_phys(struct dev_dax *dev_dax, pgoff_t pgoff,
>  }
>  EXPORT_SYMBOL_GPL(dax_pgoff_to_phys);
>  
> +#if IS_ENABLED(CONFIG_DEV_DAX_IOMAP)
> +
> +static void write_dax(void *pmem_addr, struct page *page,
> +		unsigned int off, unsigned int len)
> +{
> +	unsigned int chunk;
> +	void *mem;

I'd move these two into the loop - similar to what you have
in other cases with more local scope.

> +
> +	while (len) {
> +		mem = kmap_local_page(page);
> +		chunk = min_t(unsigned int, len, PAGE_SIZE - off);
> +		memcpy_flushcache(pmem_addr, mem + off, chunk);
> +		kunmap_local(mem);
> +		len -= chunk;
> +		off = 0;
> +		page++;
> +		pmem_addr += chunk;
> +	}
> +}
> +
> +static long __dev_dax_direct_access(struct dax_device *dax_dev, pgoff_t pgoff,
> +			long nr_pages, enum dax_access_mode mode, void **kaddr,
> +			pfn_t *pfn)
> +{
> +	struct dev_dax *dev_dax = dax_get_private(dax_dev);
> +	size_t size = nr_pages << PAGE_SHIFT;
> +	size_t offset = pgoff << PAGE_SHIFT;
> +	void *virt_addr = dev_dax->virt_addr + offset;
> +	u64 flags = PFN_DEV|PFN_MAP;

spaces around the |

Though given it's in just one place, just put these inline next
to the question...


> +	phys_addr_t phys;
> +	pfn_t local_pfn;
> +	size_t dax_size;
> +
> +	WARN_ON(!dev_dax->virt_addr);
> +
> +	if (down_read_interruptible(&dax_dev_rwsem))
> +		return 0; /* no valid data since we were killed */
> +	dax_size = dev_dax_size(dev_dax);
> +	up_read(&dax_dev_rwsem);
> +
> +	phys = dax_pgoff_to_phys(dev_dax, pgoff, nr_pages << PAGE_SHIFT);
> +
> +	if (kaddr)
> +		*kaddr = virt_addr;
> +
> +	local_pfn = phys_to_pfn_t(phys, flags); /* are flags correct? */
> +	if (pfn)
> +		*pfn = local_pfn;
> +
> +	/* This the valid size at the specified address */
> +	return PHYS_PFN(min_t(size_t, size, dax_size - offset));
> +}

> +static size_t dev_dax_recovery_write(struct dax_device *dax_dev, pgoff_t pgoff,
> +		void *addr, size_t bytes, struct iov_iter *i)
> +{
> +	size_t off;
> +
> +	off = offset_in_page(addr);

Unused.
> +
> +	return _copy_from_iter_flushcache(addr, bytes, i);
> +}