FILESYSTEM IN USERSPACE (FUSE) development
 help / color / mirror / Atom feed
From: Alison Schofield <alison.schofield@intel.com>
To: Miklos Szeredi <mszeredi@redhat.com>
Cc: <fuse-devel@lists.linux.dev>, John Groves <John@groves.net>,
	"Amir Goldstein" <amir73il@gmail.com>,
	"Darrick J . Wong" <djwong@kernel.org>,
	"Dave Jiang" <dave.jiang@intel.com>
Subject: Re: [PATCH 01/11] dax: replace exported dax_dev_get() with non-allocating dax_dev_find()
Date: Tue, 22 Sep 2026 12:07:15 -0700	[thread overview]
Message-ID: <arLR49IEKWd3ioMs@aschofie-mobl2.lan> (raw)
In-Reply-To: <20260922061019.3320196-2-mszeredi@redhat.com>

On Tue, Sep 22, 2026 at 08:10:01AM +0200, Miklos Szeredi wrote:
> From: John Groves <John@Groves.net>
> 
> This fix is in response to a Sashiko review, and some subsequent
> analysis.
> 
> dax_dev_get() uses iget5_locked() which creates a new inode if no
> matching one exists. This is correct for the internal caller
> (alloc_dax), but dangerous for external callers that look up devices
> from user-supplied or metadata-supplied dev_t values:
> 
> 1. A new inode is created with DAXDEV_ALIVE set but no backing driver,
>    no ops, and no IDA-allocated minor number.
> 
> 2. On teardown, dax_destroy_inode() warns because kill_dax() was never
>    called, and dax_free_inode() calls ida_free() for a minor that was
>    never ida_alloc'd -- potentially freeing the minor of a real device.
> 
> Add dax_dev_find() which uses ilookup5() for lookup-only semantics:
> it returns an existing dax_device with an elevated inode reference, or
> NULL if no device with the given dev_t exists. It never creates inodes.
> A dax_alive() check under dax_read_lock() guards against returning a
> device that is concurrently being torn down by kill_dax().
> 
> Make dax_dev_get() static again (internal to super.c for alloc_dax),
> export dax_dev_find() instead, and update the two external callers
> (famfs_inode.c, famfs.c). Also add the missing CONFIG_DAX=n stub.
> 
> About the 'fixes' tag: this removes the export of dax_dev_get(),
> which was flawed, and replaces is with dax_dev_find(). It feels like
> the fixes tag makes sense for correcting an ABI error.
> 
> Fixes: 2ae624d5a555d ("dax: export dax_dev_get()")
> Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> Reviewed-by: Alison Schofield <alison.schofield@intel.com>
> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
> Signed-off-by: John Groves <john@groves.net>
> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>

A couple of process things
- use get_maintainers to send this patch to the correct folks, including
  the correct mailing list, nvdimm.
- those folks and the nvdimm list should be included for the entire
  series so reviewers of this one patch can see what this is a part of.

So what is the thinking today?  Will the person who merges this
fuse-devel list work include the DAX patch in the pull request or should
I (as the dax/bus patch wrangler) plan to apply this patch?

FWIW, we looked at this patch last merge window and decided to
wait for fuse to land before making further changes to DAX for FUSE.

-- Alison


  



> ---
>  drivers/dax/super.c | 38 ++++++++++++++++++++++++++++++++++++--
>  include/linux/dax.h |  6 +++++-
>  2 files changed, 41 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> index 45f84b0eb909..824e1f6df378 100644
> --- a/drivers/dax/super.c
> +++ b/drivers/dax/super.c
> @@ -565,7 +565,7 @@ static int dax_set(struct inode *inode, void *data)
>  	return 0;
>  }
>  
> -struct dax_device *dax_dev_get(dev_t devt)
> +static struct dax_device *dax_dev_get(dev_t devt)
>  {
>  	struct dax_device *dax_dev;
>  	struct inode *inode;
> @@ -588,7 +588,41 @@ struct dax_device *dax_dev_get(dev_t devt)
>  
>  	return dax_dev;
>  }
> -EXPORT_SYMBOL_GPL(dax_dev_get);
> +
> +/**
> + * dax_dev_find - look up an existing dax_device by dev_t
> + * @devt: the device number to find
> + *
> + * Returns a dax_device with an elevated inode reference, or NULL if no
> + * device with the given dev_t exists. Unlike dax_dev_get(), this never
> + * allocates a new inode -- it is safe for external callers that are looking
> + * up devices from user-supplied or metadata-supplied dev_t values.
> + *
> + * Caller must put_dax() the returned device when done.
> + */
> +struct dax_device *dax_dev_find(dev_t devt)
> +{
> +	struct dax_device *dax_dev;
> +	struct inode *inode;
> +	int id;
> +
> +	inode = ilookup5(dax_superblock, hash_32(devt + DAXFS_MAGIC, 31),
> +			 dax_test, &devt);
> +	if (!inode)
> +		return NULL;
> +
> +	dax_dev = to_dax_dev(inode);
> +	id = dax_read_lock();
> +	if (!dax_alive(dax_dev)) {
> +		dax_read_unlock(id);
> +		iput(inode);
> +		return NULL;
> +	}
> +	dax_read_unlock(id);
> +
> +	return dax_dev;
> +}
> +EXPORT_SYMBOL_GPL(dax_dev_find);
>  
>  struct dax_device *alloc_dax(void *private, const struct dax_operations *ops)
>  {
> diff --git a/include/linux/dax.h b/include/linux/dax.h
> index fe6c3ded1b50..29113eb95e72 100644
> --- a/include/linux/dax.h
> +++ b/include/linux/dax.h
> @@ -54,7 +54,7 @@ struct dax_device *alloc_dax(void *private, const struct dax_operations *ops);
>  void *dax_holder(struct dax_device *dax_dev);
>  void put_dax(struct dax_device *dax_dev);
>  void kill_dax(struct dax_device *dax_dev);
> -struct dax_device *dax_dev_get(dev_t devt);
> +struct dax_device *dax_dev_find(dev_t devt);
>  void dax_write_cache(struct dax_device *dax_dev, bool wc);
>  bool dax_write_cache_enabled(struct dax_device *dax_dev);
>  bool dax_synchronous(struct dax_device *dax_dev);
> @@ -92,6 +92,10 @@ static inline void put_dax(struct dax_device *dax_dev)
>  static inline void kill_dax(struct dax_device *dax_dev)
>  {
>  }
> +static inline struct dax_device *dax_dev_find(dev_t devt)
> +{
> +	return NULL;
> +}
>  static inline void dax_write_cache(struct dax_device *dax_dev, bool wc)
>  {
>  }
> -- 
> 2.54.0
> 

  parent reply	other threads:[~2026-09-22 19:07 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-22  6:10 [PATCH 00/11] fuse: DAX device based extent maps (famfs) Miklos Szeredi
2026-09-22  6:10 ` [PATCH 01/11] dax: replace exported dax_dev_get() with non-allocating dax_dev_find() Miklos Szeredi
2026-09-22  7:36   ` Amir Goldstein
2026-09-22 19:07   ` Alison Schofield [this message]
2026-09-28  9:16     ` Miklos Szeredi
2026-09-22  6:10 ` [PATCH 02/11] fuse: use "vdax" naming for virtiofs DAX Miklos Szeredi
2026-09-22  8:43   ` Amir Goldstein
2026-09-28 10:38     ` Miklos Szeredi
2026-10-01 13:18       ` Amir Goldstein
2026-09-22  6:10 ` [PATCH 03/11] fuse: don't assume ff->passthrough is set for FOPEN_PASSTHROUGH Miklos Szeredi
2026-09-22  8:44   ` Amir Goldstein
2026-09-22  6:10 ` [PATCH 04/11] fuse: make fuse_backing_get() static Miklos Szeredi
2026-09-22  8:44   ` Amir Goldstein
2026-09-22  6:10 ` [PATCH 05/11] fuse: add helpers for EIO return value with kernel message Miklos Szeredi
2026-09-22  9:58   ` Amir Goldstein
2026-09-28 10:57     ` Miklos Szeredi
2026-09-22  6:10 ` [PATCH 06/11] fuse: support 64 bit, server allocated backing ID Miklos Szeredi
2026-09-22 10:29   ` Amir Goldstein
2026-09-23  7:08   ` Amir Goldstein
2026-09-30 10:15     ` Miklos Szeredi
2026-09-30 10:48       ` Amir Goldstein
2026-09-22  6:10 ` [PATCH 07/11] fuse: support opening 64 bit " Miklos Szeredi
2026-09-22 10:33   ` Amir Goldstein
2026-09-22  6:10 ` [PATCH 08/11] fuse: add support for opening dax device as backing Miklos Szeredi
2026-09-22 11:00   ` Amir Goldstein
2026-10-01 15:06     ` Amir Goldstein
2026-10-01 15:34       ` Miklos Szeredi
2026-09-22  6:10 ` [PATCH 09/11] fuse: add extent map data structure Miklos Szeredi
2026-09-22 12:57   ` Amir Goldstein
2026-09-22  6:10 ` [PATCH 10/11] fuse: add extent map I/O support Miklos Szeredi
2026-09-22 13:04   ` Amir Goldstein
2026-09-22  6:10 ` [PATCH 11/11] fuse: add support for striped backing Miklos Szeredi
2026-09-23  5:41   ` Amir Goldstein

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=arLR49IEKWd3ioMs@aschofie-mobl2.lan \
    --to=alison.schofield@intel.com \
    --cc=John@groves.net \
    --cc=amir73il@gmail.com \
    --cc=dave.jiang@intel.com \
    --cc=djwong@kernel.org \
    --cc=fuse-devel@lists.linux.dev \
    --cc=mszeredi@redhat.com \
    /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