All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: John Groves <John@Groves.net>
Cc: Dan Williams <dan.j.williams@intel.com>,
	Miklos Szeredi <miklos@szeredb.hu>,
	Bernd Schubert <bschubert@ddn.com>,
	John Groves <jgroves@micron.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Vishal Verma <vishal.l.verma@intel.com>,
	Dave Jiang <dave.jiang@intel.com>,
	"Matthew Wilcox" <willy@infradead.org>, Jan Kara <jack@suse.cz>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>,
	"Darrick J . Wong" <djwong@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	"Jeff Layton" <jlayton@kernel.org>,
	Kent Overstreet <kent.overstreet@linux.dev>,
	<linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<nvdimm@lists.linux.dev>, <linux-cxl@vger.kernel.org>,
	<linux-fsdevel@vger.kernel.org>,
	Amir Goldstein <amir73il@gmail.com>,
	"Stefan Hajnoczi" <shajnocz@redhat.com>,
	Joanne Koong <joannelkoong@gmail.com>,
	Josef Bacik <josef@toxicpanda.com>,
	Aravind Ramesh <arramesh@micron.com>,
	Ajay Joshi <ajayjoshi@micron.com>
Subject: Re: [RFC V2 03/18] dev_dax_iomap: Save the kva from memremap
Date: Fri, 4 Jul 2025 12:11:19 +0100	[thread overview]
Message-ID: <20250704121119.00002846@huawei.com> (raw)
In-Reply-To: <20250703185032.46568-4-john@groves.net>

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

> Save the kva from memremap because we need it for iomap rw support.
> 
> Prior to famfs, there were no iomap users of /dev/dax - so the virtual
> address from memremap was not needed.
> 
> Also: in some cases dev_dax_probe() is called with the first
> dev_dax->range offset past the start of pgmap[0].range. In those cases
> we need to add the difference to virt_addr in order to have the physaddr's
> in dev_dax->ranges match dev_dax->virt_addr.
> 
> This happens with devdax devices that started as pmem and got converted
> to devdax. I'm not sure whether the offset is due to label storage, or
> page tables, but this works in all known cases.

Clearly a question we need to resolve to understand if this is correct
handling.

> 
> Signed-off-by: John Groves <john@groves.net>
> ---
>  drivers/dax/dax-private.h |  1 +
>  drivers/dax/device.c      | 15 +++++++++++++++
>  2 files changed, 16 insertions(+)
> 
> diff --git a/drivers/dax/dax-private.h b/drivers/dax/dax-private.h
> index 0867115aeef2..2a6b07813f9f 100644
> --- a/drivers/dax/dax-private.h
> +++ b/drivers/dax/dax-private.h
> @@ -81,6 +81,7 @@ struct dev_dax_range {
>  struct dev_dax {
>  	struct dax_region *region;
>  	struct dax_device *dax_dev;
> +	void *virt_addr;
>  	unsigned int align;
>  	int target_node;
>  	bool dyn_id;
> diff --git a/drivers/dax/device.c b/drivers/dax/device.c
> index 29f61771fef0..583150478dcc 100644
> --- a/drivers/dax/device.c
> +++ b/drivers/dax/device.c
> @@ -372,6 +372,7 @@ static int dev_dax_probe(struct dev_dax *dev_dax)
>  	struct dax_device *dax_dev = dev_dax->dax_dev;
>  	struct device *dev = &dev_dax->dev;
>  	struct dev_pagemap *pgmap;
> +	u64 data_offset = 0;
>  	struct inode *inode;
>  	struct cdev *cdev;
>  	void *addr;
> @@ -426,6 +427,20 @@ static int dev_dax_probe(struct dev_dax *dev_dax)
>  	if (IS_ERR(addr))
>  		return PTR_ERR(addr);
>  
> +	/* Detect whether the data is at a non-zero offset into the memory */
> +	if (pgmap->range.start != dev_dax->ranges[0].range.start) {

Using pgmap->range.start here but then getting to the same (I think)
with  dev_dax->pgmap[0].range.start is rather inconsistent.

Also, perhaps drag the assignment of phys and pgmap_phys out of this
scope so that you can use them for the condition check above and
then reuse the same in here.


> +		u64 phys = dev_dax->ranges[0].range.start;
> +		u64 pgmap_phys = dev_dax->pgmap[0].range.start;
> +		u64 vmemmap_shift = dev_dax->pgmap[0].vmemmap_shift;
> +
> +		if (!WARN_ON(pgmap_phys > phys))
> +			data_offset = phys - pgmap_phys;

In the event of the condition above being false.
phys == pgmap_phys and data_offset == 0.

So why not do this unconditionally replacing this block with something like

	/* Apply necessary offset */

	dev_dax->virt_addr = addr +
		(dev_dax->ranges[0].range.start - pgmap->range.start);
> +
> +		pr_debug("%s: offset detected phys=%llx pgmap_phys=%llx offset=%llx shift=%llx\n",
> +		       __func__, phys, pgmap_phys, data_offset, vmemmap_shift);

If it's only used in the print, I'd just put the path to vmemmap_shift directly in here
and probably get to it via pgmap->vmemmap_shift



> +	}
> +	dev_dax->virt_addr = addr + data_offset;
> +
>  	inode = dax_inode(dax_dev);
>  	cdev = inode->i_cdev;
>  	cdev_init(cdev, &dax_fops);


  reply	other threads:[~2025-07-04 11:29 UTC|newest]

Thread overview: 91+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-03 18:50 [RFC V2 00/18] famfs: port into fuse John Groves
2025-07-03 18:50 ` [RFC V2 01/18] dev_dax_iomap: Move dax_pgoff_to_phys() from device.c to bus.c John Groves
2025-07-03 18:50 ` [RFC V2 02/18] dev_dax_iomap: Add fs_dax_get() func to prepare dax for fs-dax usage John Groves
2025-07-04 10:39   ` Jonathan Cameron
2025-07-04 12:54     ` John Groves
2025-07-03 18:50 ` [RFC V2 03/18] dev_dax_iomap: Save the kva from memremap John Groves
2025-07-04 11:11   ` Jonathan Cameron [this message]
2025-07-03 18:50 ` [RFC V2 04/18] dev_dax_iomap: Add dax_operations for use by fs-dax on devdax John Groves
2025-07-04 12:47   ` Jonathan Cameron
2025-07-05 22:56     ` John Groves
2025-07-03 18:50 ` [RFC V2 05/18] dev_dax_iomap: export dax_dev_get() John Groves
2025-07-03 18:50 ` [RFC V2 06/18] dev_dax_iomap: (ignore!) Drop poisoned page warning in fs/dax.c John Groves
2025-07-03 18:50 ` [RFC V2 07/18] famfs_fuse: magic.h: Add famfs magic numbers John Groves
2025-07-03 18:50 ` [RFC V2 08/18] famfs_fuse: Kconfig John Groves
2025-07-03 18:50 ` [RFC V2 09/18] famfs_fuse: Update macro s/FUSE_IS_DAX/FUSE_IS_VIRTIO_DAX/ John Groves
2025-07-04  8:44   ` Amir Goldstein
2025-07-03 18:50 ` [RFC V2 10/18] famfs_fuse: Basic fuse kernel ABI enablement for famfs John Groves
2025-07-03 22:45   ` John Groves
2025-07-07 17:32     ` Darrick J. Wong
2025-07-04  7:54   ` Amir Goldstein
2025-07-04 13:39     ` John Groves
2025-07-07 17:39       ` Darrick J. Wong
2025-07-08 12:02         ` John Groves
2025-07-09  1:53           ` Darrick J. Wong
2025-07-11  1:32             ` John Groves
2025-07-12  4:49               ` Darrick J. Wong
2025-08-11 18:30               ` John Groves
2025-08-12 16:37                 ` Darrick J. Wong
2025-08-13 13:07                   ` John Groves
2025-08-14 17:16                     ` Darrick J. Wong
2025-07-03 18:50 ` [RFC V2 11/18] famfs_fuse: Basic famfs mount opts John Groves
2025-07-09  3:59   ` Darrick J. Wong
2025-07-11 15:28     ` John Groves
2025-07-12  5:54       ` Darrick J. Wong
2025-08-14 10:37         ` Miklos Szeredi
2025-08-14 14:39           ` John Groves
2025-08-14 15:19             ` Miklos Szeredi
2025-08-14 23:52               ` John Groves
2025-07-03 18:50 ` [RFC V2 12/18] famfs_fuse: Plumb the GET_FMAP message/response John Groves
2025-07-04  8:54   ` Amir Goldstein
2025-07-04 20:30     ` John Groves
2025-07-05  0:06       ` John Groves
2025-07-05  7:58         ` Amir Goldstein
2025-07-05 19:17           ` John Groves
2025-07-09  4:27   ` Darrick J. Wong
2025-07-11 13:46     ` John Groves
2025-08-14 13:36   ` Miklos Szeredi
2025-08-14 14:36     ` Miklos Szeredi
2025-08-14 18:20       ` Darrick J. Wong
2025-08-15 15:06         ` John Groves
2025-08-19 21:55           ` Darrick J. Wong
2025-08-15 16:53       ` John Groves
2025-08-19 22:13         ` Darrick J. Wong
2025-08-14 18:05     ` Darrick J. Wong
2025-08-16 15:00       ` John Groves
2025-08-19 22:17         ` Darrick J. Wong
2025-08-15  0:38     ` John Groves
2025-07-03 18:50 ` [RFC V2 13/18] famfs_fuse: Create files with famfs fmaps John Groves
2025-07-04  9:01   ` Amir Goldstein
2025-07-05 19:27     ` John Groves
2025-07-03 18:50 ` [RFC V2 14/18] famfs_fuse: GET_DAXDEV message and daxdev_table John Groves
2025-07-04 13:20   ` Jonathan Cameron
2025-07-06 17:07     ` John Groves
2025-08-14 13:58   ` Miklos Szeredi
2025-08-14 17:19     ` Darrick J. Wong
2025-08-14 18:25       ` Miklos Szeredi
2025-08-14 18:55         ` Darrick J. Wong
2025-08-14 19:19           ` Miklos Szeredi
2025-08-16 16:22         ` John Groves
2025-08-19 22:32           ` Darrick J. Wong
2025-08-15 16:38     ` John Groves
2025-08-19 22:34       ` Darrick J. Wong
2025-07-03 18:50 ` [RFC V2 15/18] famfs_fuse: Plumb dax iomap and fuse read/write/mmap John Groves
2025-07-04  9:13   ` Amir Goldstein
2025-07-05 19:44     ` John Groves
2025-07-03 18:50 ` [RFC V2 16/18] famfs_fuse: Add holder_operations for dax notify_failure() John Groves
2025-07-03 18:50 ` [RFC V2 17/18] famfs_fuse: Add famfs metadata documentation John Groves
2025-07-03 18:50 ` [RFC V2 18/18] famfs_fuse: Add documentation John Groves
2025-07-04  0:27   ` Bagas Sanjaya
2025-07-04  2:22     ` Jonathan Corbet
2025-07-04  3:53       ` Bagas Sanjaya
2025-07-04 18:58         ` Matthew Wilcox
2025-07-04 23:29           ` Bagas Sanjaya
2025-07-04 23:43             ` Matthew Wilcox
2025-07-05  1:11               ` Bagas Sanjaya
2025-07-04  6:09   ` Randy Dunlap
2025-07-04  8:27   ` Amir Goldstein
2025-07-04 23:36     ` Bagas Sanjaya
2025-07-03 18:56 ` [RFC V2 00/18] famfs: port into fuse John Groves
2025-07-09  3:26   ` Miklos Szeredi
2025-07-11  1:18     ` John Groves

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=20250704121119.00002846@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=John@Groves.net \
    --cc=ajayjoshi@micron.com \
    --cc=amir73il@gmail.com \
    --cc=arramesh@micron.com \
    --cc=brauner@kernel.org \
    --cc=bschubert@ddn.com \
    --cc=corbet@lwn.net \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=djwong@kernel.org \
    --cc=jack@suse.cz \
    --cc=jgroves@micron.com \
    --cc=jlayton@kernel.org \
    --cc=joannelkoong@gmail.com \
    --cc=josef@toxicpanda.com \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredb.hu \
    --cc=nvdimm@lists.linux.dev \
    --cc=rdunlap@infradead.org \
    --cc=shajnocz@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.