public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alison Schofield <alison.schofield@intel.com>
To: John Groves <john@jagalactic.com>
Cc: John Groves <John@groves.net>, Miklos Szeredi <miklos@szeredi.hu>,
	"Dan Williams" <dan.j.williams@intel.com>,
	Bernd Schubert <bschubert@ddn.com>,
	"John Groves" <jgroves@micron.com>,
	John Groves <jgroves@fastmail.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>,
	David Hildenbrand <david@kernel.org>,
	Christian Brauner <brauner@kernel.org>,
	"Darrick J . Wong" <djwong@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Jeff Layton <jlayton@kernel.org>,
	Amir Goldstein <amir73il@gmail.com>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Stefan Hajnoczi <shajnocz@redhat.com>,
	"Joanne Koong" <joannelkoong@gmail.com>,
	Josef Bacik <josef@toxicpanda.com>,
	"Bagas Sanjaya" <bagasdotme@gmail.com>,
	James Morse <james.morse@arm.com>, Fuad Tabba <tabba@google.com>,
	Sean Christopherson <seanjc@google.com>,
	Shivank Garg <shivankg@amd.com>,
	Ackerley Tng <ackerleytng@google.com>,
	Gregory Price <gourry@gourry.net>,
	Aravind Ramesh <arramesh@micron.com>,
	Ajay Joshi <ajayjoshi@micron.com>,
	"venkataravis@micron.com" <venkataravis@micron.com>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"nvdimm@lists.linux.dev" <nvdimm@lists.linux.dev>,
	"linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH V4 1/2] daxctl: Add support for famfs mode
Date: Mon, 20 Apr 2026 16:17:09 -0700	[thread overview]
Message-ID: <aeaz9TecrINXaHcR@aschofie-mobl2.lan> (raw)
In-Reply-To: <aaD6yQLiyZznfAxr@aschofie-mobl2.lan>

On Thu, Feb 26, 2026 at 06:00:41PM -0800, Alison Schofield wrote:
> On Sun, Jan 18, 2026 at 10:36:38PM +0000, John Groves wrote:
> > From: John Groves <John@Groves.net>
> > 

Hi John,

This is where I left off with the actual changes to "daxctl" for FAMFS.
We need a new rev of this ndctl set that includes both patches rebased
on ndctl pending and addressing the review comments below for daxctl.
(Although I've used more recent branches, I haven't looked at whether
these issues were addressed in the code.)

With a new rev, I'll take another look at ensuring a dax device is
available for the unit test.

Thanks!

--Alison


> > Putting a daxdev in famfs mode means binding it to fsdev_dax.ko
> > (drivers/dax/fsdev.c). Finding a daxdev bound to fsdev_dax means
> > it is in famfs mode.
> > 
> > The test is added to the destructive test suite since it
> > modifies device modes.
> 
> Make it clear that it is added in a separate patch. (and assume you
> can drop the destructive part too.)
> 
> > 
> > With devdax, famfs, and system-ram modes, the previous logic that assumed
> > 'not in mode X means in mode Y' needed to get slightly more complicated
> > 
> > Add explicit mode detection functions:
> > - daxctl_dev_is_famfs_mode(): check if bound to fsdev_dax driver
> > - daxctl_dev_is_devdax_mode(): check if bound to device_dax driver
> 
> 
> The precedence check (ram->famfs->devdax->unknown) now happens in multiple
> places. How about adding a daxctl_dev_get_mode() helper to centralize that.
> It could be private for now, unless you expect external users to need it.
> 
> daxctl_dev_is_famfs_mode() and _is_devdax_mode() are nearly identical aside
> from the module name. Refactoring the shared part into a single helper will
> also make it easier to add a daxctl_dev_get_mode() without duplicating the
> precedence logic.
> 
> > 
> > Fix mode transition logic in device.c:
> > - disable_devdax_device(): verify device is actually in devdax mode
> > - disable_famfs_device(): verify device is actually in famfs mode
> > - All reconfig_mode_*() functions now explicitly check each mode
> > - Handle unknown mode with error instead of wrong assumption
> 
> Wondering about 'Fix' mode transition logic. Was prior logic broken and
> should any of these changes be in a precursor patch that is a 'fix'.
> 
> 
> > 
> > Modify json.c to show 'unknown' if device is not in a recognized mode.
> 
> I think this means disabled devices will always look unknown even when
> the intended mode is devdax or famfs, but disabled. This seems to
> change the meaning of mode from 'configured' to 'active' personality.
> Can you detect the configured mode even when disabled?
> Perhaps a man page change about this new behavior?
> 
> snip
> 
> 
> >  
> > @@ -724,11 +767,21 @@ static int reconfig_mode_system_ram(struct daxctl_dev *dev)
> >  	}
> >  
> >  	if (daxctl_dev_is_enabled(dev)) {
> > -		rc = disable_devdax_device(dev);
> > -		if (rc < 0)
> > -			return rc;
> > -		if (rc > 0)
> 
> Please check the return code semantics.
> This gets rid of the <0 vs >0 distinction. That means a '1' skip
> becomes an error return to the caller. Is that what you want?
> 
> Previously, we had a return 1 from disable_devdax_device for
> “not applicable / already in other mode” and I think that is now
> gone.
> 
> 
> > +		if (mem) {
> > +			/* already in system-ram mode */
> >  			skip_enable = 1;
> > +		} else if (daxctl_dev_is_famfs_mode(dev)) {
> > +			rc = disable_famfs_device(dev);
> > +			if (rc)
> > +				return rc;
> > +		} else if (daxctl_dev_is_devdax_mode(dev)) {
> > +			rc = disable_devdax_device(dev);
> > +			if (rc)
> > +				return rc;
> > +		} else {
> > +			fprintf(stderr, "%s: unknown mode\n", devname);
> > +			return -EINVAL;
> > +		}
> >  	}
> >  
> 
> snip
> 
> >  static int reconfig_mode_devdax(struct daxctl_dev *dev)
> >  {
> > +	struct daxctl_memory *mem = daxctl_dev_get_memory(dev);
> > +	const char *devname = daxctl_dev_get_devname(dev);
> >  	int rc;
> >  
> >  	if (daxctl_dev_is_enabled(dev)) {
> > -		rc = disable_system_ram_device(dev);
> > -		if (rc)
> > -			return rc;
> > +		if (mem) {
> > +			rc = disable_system_ram_device(dev);
> > +			if (rc)
> > +				return rc;
> > +		} else if (daxctl_dev_is_famfs_mode(dev)) {
> > +			rc = disable_famfs_device(dev);
> > +			if (rc)
> > +				return rc;
> > +		} else if (daxctl_dev_is_devdax_mode(dev)) {
> > +			/* already in devdax mode, just re-enable */
> > +			rc = daxctl_dev_disable(dev);
> > +			if (rc)
> 
> disable_* helpers print an error message on disable failure.
> Seems this should too.
> 
> 
> > +				return rc;
> > +		} else {
> > +			fprintf(stderr, "%s: unknown mode\n", devname);
> > +			return -EINVAL;
> > +		}
> >  	}
> >  
> >  	rc = daxctl_dev_enable_devdax(dev);
> > @@ -801,6 +870,40 @@ static int reconfig_mode_devdax(struct daxctl_dev *dev)
> >  	return 0;
> >  }
> >  
> > +static int reconfig_mode_famfs(struct daxctl_dev *dev)
> > +{
> > +	struct daxctl_memory *mem = daxctl_dev_get_memory(dev);
> > +	const char *devname = daxctl_dev_get_devname(dev);
> > +	int rc;
> > +
> > +	if (daxctl_dev_is_enabled(dev)) {
> > +		if (mem) {
> > +			fprintf(stderr,
> > +				"%s is in system-ram mode, must be in devdax mode to convert to famfs\n",
> > +				devname);
> > +			return -EINVAL;
> > +		} else if (daxctl_dev_is_famfs_mode(dev)) {
> > +			/* already in famfs mode, just re-enable */
> > +			rc = daxctl_dev_disable(dev);
> > +			if (rc)
> > +				return rc;
> > +		} else if (daxctl_dev_is_devdax_mode(dev)) {
> > +			rc = disable_devdax_device(dev);
> > +			if (rc)
> 
> and here too...the disable error message.
> 
> 
> > +				return rc;
> > +		} else {
> > +			fprintf(stderr, "%s: unknown mode\n", devname);
> > +			return -EINVAL;
> > +		}
> > +	}
> > +
> > +	rc = daxctl_dev_enable_famfs(dev);
> > +	if (rc)
> > +		return rc;
> > +
> > +	return 0;
> > +}
> 
> snip
> 
> > +DAXCTL_EXPORT int daxctl_dev_is_famfs_mode(struct daxctl_dev *dev)
> > +{
> > +	const char *devname = daxctl_dev_get_devname(dev);
> > +	struct daxctl_ctx *ctx = daxctl_dev_get_ctx(dev);
> > +	char *mod_path, *mod_base;
> > +	char path[200];
> 
> We have PATH_MAX for the above.
> 
> > +	const int len = sizeof(path);
> > +
> > +	if (!device_model_is_dax_bus(dev))
> > +		return false;
> > +
> > +	if (!daxctl_dev_is_enabled(dev))
> > +		return false;
> > +
> > +	if (snprintf(path, len, "%s/driver", dev->dev_path) >= len) {
> > +		err(ctx, "%s: buffer too small!\n", devname);
> > +		return false;
> > +	}
> > +
> > +	mod_path = realpath(path, NULL);
> > +	if (!mod_path)
> 
> Maybe a dbg() level err msg here
> 
> > +		return false;
> > +
> > +	mod_base = basename(mod_path);
> 
> Please use path_basename() because of this:
> https://lore.kernel.org/all/20260116043056.542346-1-alison.schofield@intel.com/
> 
> Give me a minute ;) to push that to the pending branch and you can
> work from there: https://github.com/pmem/ndctl/commits/pending/
> 
> snip to end.

  reply	other threads:[~2026-04-20 23:17 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260118222911.92214-1-john@jagalactic.com>
2026-01-18 22:29 ` [PATCH BUNDLE v7] famfs: Fabric-Attached Memory File System John Groves
2026-01-18 22:30   ` [PATCH V7 00/19] famfs: port into fuse John Groves
2026-01-18 22:31     ` [PATCH V7 01/19] dax: move dax_pgoff_to_phys from [drivers/dax/] device.c to bus.c John Groves
2026-02-11 14:23       ` Ira Weiny
2026-02-18 23:00       ` Dave Jiang
2026-01-18 22:31     ` [PATCH V7 02/19] dax: Factor out dax_folio_reset_order() helper John Groves
2026-02-13 21:24       ` Ira Weiny
2026-02-18 23:04       ` Dave Jiang
2026-02-24  3:00       ` Ackerley Tng
2026-03-02 15:06         ` John Groves
2026-03-09  6:27           ` Ackerley Tng
2026-01-18 22:31     ` [PATCH V7 03/19] dax: add fsdev.c driver for fs-dax on character dax John Groves
2026-02-13 21:05       ` Ira Weiny
2026-02-17 17:56         ` John Groves
2026-03-19 15:11           ` Jonathan Cameron
2026-01-18 22:31     ` [PATCH V7 04/19] dax: Save the kva from memremap John Groves
2026-02-13 21:23       ` Ira Weiny
2026-02-18 23:33       ` Dave Jiang
2026-01-18 22:31     ` [PATCH V7 05/19] dax: Add dax_operations for use by fs-dax on fsdev dax John Groves
2026-02-13 21:23       ` Ira Weiny
2026-02-18  0:38         ` John Groves
2026-02-14 16:10       ` Ira Weiny
2026-02-18  0:49         ` John Groves
2026-01-18 22:32     ` [PATCH V7 06/19] dax: Add dax_set_ops() for setting dax_operations at bind time John Groves
2026-02-19 15:41       ` Dave Jiang
2026-01-18 22:32     ` [PATCH V7 07/19] dax: Add fs_dax_get() func to prepare dax for fs-dax usage John Groves
2026-02-19 16:07       ` Dave Jiang
2026-02-26 23:20         ` John Groves
2026-01-18 22:32     ` [PATCH V7 08/19] dax: export dax_dev_get() John Groves
2026-02-19 16:18       ` Dave Jiang
2026-01-18 22:32     ` [PATCH V7 09/19] famfs_fuse: magic.h: Add famfs magic numbers John Groves
2026-02-19 16:21       ` Dave Jiang
2026-01-18 22:32     ` [PATCH V7 10/19] famfs_fuse: Update macro s/FUSE_IS_DAX/FUSE_IS_VIRTIO_DAX/ John Groves
2026-02-19 16:33       ` Dave Jiang
2026-01-18 22:32     ` [PATCH V7 11/19] famfs_fuse: Basic fuse kernel ABI enablement for famfs John Groves
2026-02-19 16:57       ` Dave Jiang
2026-01-18 22:33     ` [PATCH V7 12/19] famfs_fuse: Plumb the GET_FMAP message/response John Groves
2026-02-19 17:12       ` Dave Jiang
2026-02-26  0:24         ` John Groves
2026-01-18 22:33     ` [PATCH V7 13/19] famfs_fuse: Create files with famfs fmaps John Groves
2026-02-19 18:31       ` Dave Jiang
2026-02-25 21:30         ` John Groves
2026-01-18 22:33     ` [PATCH V7 14/19] famfs_fuse: GET_DAXDEV message and daxdev_table John Groves
2026-02-19 18:51       ` Dave Jiang
2026-02-25 23:51         ` John Groves
2026-01-18 22:33     ` [PATCH V7 15/19] famfs_fuse: Plumb dax iomap and fuse read/write/mmap John Groves
2026-01-18 22:33     ` [PATCH V7 16/19] famfs_fuse: Add holder_operations for dax notify_failure() John Groves
2026-01-18 22:33     ` [PATCH V7 17/19] famfs_fuse: Add DAX address_space_operations with noop_dirty_folio John Groves
2026-01-30 23:13       ` Joanne Koong
2026-01-18 22:34     ` [PATCH V7 18/19] famfs_fuse: Add famfs fmap metadata documentation John Groves
2026-02-19 20:22       ` Dave Jiang
2026-01-18 22:34     ` [PATCH V7 19/19] famfs_fuse: Add documentation John Groves
2026-02-19 21:39       ` Dave Jiang
2026-02-26  0:29         ` John Groves
2026-01-18 22:34   ` [PATCH V7 0/3] libfuse: add basic famfs support to libfuse John Groves
2026-01-18 22:35     ` [PATCH V7 1/3] fuse_kernel.h: bring up to baseline 6.19 John Groves
2026-01-30 22:53       ` Joanne Koong
2026-01-31  0:41         ` Darrick J. Wong
2026-01-31  1:18           ` Joanne Koong
2026-01-18 22:35     ` [PATCH V7 2/3] fuse_kernel.h: add famfs DAX fmap protocol definitions John Groves
2026-01-18 22:35     ` [PATCH V7 3/3] fuse: add famfs DAX fmap support John Groves
2026-01-18 22:36   ` [PATCH V4 0/2] ndctl: Add daxctl support for the new "famfs" mode of devdax John Groves
2026-01-18 22:36     ` [PATCH V4 1/2] daxctl: Add support for famfs mode John Groves
2026-02-19 21:47       ` Dave Jiang
2026-02-27  2:00       ` Alison Schofield
2026-04-20 23:17         ` Alison Schofield [this message]
2026-04-21  1:47           ` John Groves
2026-04-22 18:09             ` Ira Weiny
2026-01-18 22:36     ` [PATCH V4 2/2] Add test/daxctl-famfs.sh to test famfs mode transitions: John Groves
2026-02-19 22:02       ` Dave Jiang
2026-01-20 17:01     ` [PATCH V4 0/2] ndctl: Add daxctl support for the new "famfs" mode of devdax Alireza Sanaee
2026-01-20 17:05       ` John Groves
2026-02-09 23:13     ` Alison Schofield
2026-02-11 14:31       ` John Groves
2026-01-20  9:12   ` [PATCH BUNDLE v7] famfs: Fabric-Attached Memory File System Alireza Sanaee
2026-01-20 15:13     ` 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=aeaz9TecrINXaHcR@aschofie-mobl2.lan \
    --to=alison.schofield@intel.com \
    --cc=John@groves.net \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=ackerleytng@google.com \
    --cc=ajayjoshi@micron.com \
    --cc=amir73il@gmail.com \
    --cc=arramesh@micron.com \
    --cc=bagasdotme@gmail.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=david@kernel.org \
    --cc=djwong@kernel.org \
    --cc=gourry@gourry.net \
    --cc=jack@suse.cz \
    --cc=james.morse@arm.com \
    --cc=jgroves@fastmail.com \
    --cc=jgroves@micron.com \
    --cc=jlayton@kernel.org \
    --cc=joannelkoong@gmail.com \
    --cc=john@jagalactic.com \
    --cc=josef@toxicpanda.com \
    --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@szeredi.hu \
    --cc=nvdimm@lists.linux.dev \
    --cc=rdunlap@infradead.org \
    --cc=seanjc@google.com \
    --cc=shajnocz@redhat.com \
    --cc=shivankg@amd.com \
    --cc=tabba@google.com \
    --cc=venkataravis@micron.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox