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.
next prev parent 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