From: John Groves <John@groves.net>
To: Dave Jiang <dave.jiang@intel.com>
Cc: John Groves <john@jagalactic.com>, Dan Williams <djbw@kernel.org>,
John Groves <jgroves@micron.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Matthew Wilcox <willy@infradead.org>, Jan Kara <jack@suse.cz>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
Miklos Szeredi <miklos@szeredi.hu>,
Alison Schofield <alison.schofield@intel.com>,
Ira Weiny <iweiny@kernel.org>,
Jonathan Cameron <jic23@kernel.org>,
"nvdimm@lists.linux.dev" <nvdimm@lists.linux.dev>,
"linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH V2 6/7] dax: replace exported dax_dev_get() with non-allocating dax_dev_find()
Date: Sat, 30 May 2026 09:19:39 -0500 [thread overview]
Message-ID: <ahrwrBuEzQaFQ66i@groves.net> (raw)
In-Reply-To: <a7ea31ac-8aca-4ff5-adf1-7b3941eba5b4@intel.com>
On 26/05/26 05:28PM, Dave Jiang wrote:
>
>
> On 5/22/26 12:19 PM, John Groves 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.
> >
> > 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.
> >
> > Fixes: 2ae624d5a555d ("dax: export dax_dev_get()")
> > Signed-off-by: John Groves <john@groves.net>
> > ---
> > drivers/dax/super.c | 27 +++++++++++++++++++++++++--
> > include/linux/dax.h | 6 +++++-
> > 2 files changed, 30 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> > index fa1d2a6eb2408..79e5823d1010d 100644
> > --- a/drivers/dax/super.c
> > +++ b/drivers/dax/super.c
> > @@ -541,7 +541,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;
> > @@ -564,7 +564,30 @@ 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 inode *inode;
> > +
> > + inode = ilookup5(dax_superblock, hash_32(devt + DAXFS_MAGIC, 31),
> > + dax_test, &devt);
> > + if (!inode)
> > + return NULL;
> > +
>
> Claude mentions that dax_alive() check may be a good idea after grabbing the inode ref. Otherwise famfs may get a dax_dev that may be racing with a teardown. Do something similar that fs_dax_get_by_dev() or fs_dax_get() do WRT dax_alive() check perhaps.
>
> DJ
I think that's right. Calling dax_alive() requires a dax_read_lock();
Adding that too.
Thanks!
John
<snip>
next prev parent reply other threads:[~2026-05-30 14:19 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260522191804.79088-1-john@jagalactic.com>
2026-05-22 19:18 ` [PATCH V2 0/7] Fixes to the previously-merged drivers/dax/fsdev series John Groves
2026-05-22 19:18 ` [PATCH V2 1/7] dax: fix misleading comment about share/index union in dax_folio_reset_order() John Groves
2026-05-26 23:07 ` Dave Jiang
2026-05-29 23:41 ` John Groves
2026-05-22 19:18 ` [PATCH V2 2/7] dax/fsdev: fix multi-range offset, vmemmap_shift leak, and probe error cleanup John Groves
2026-05-26 23:22 ` Dave Jiang
2026-05-29 23:59 ` John Groves
2026-05-22 19:19 ` [PATCH V2 3/7] dax/fsdev: fix kaddr for multi-range and fail probe on invalid pgmap offset John Groves
2026-05-26 23:31 ` Dave Jiang
2026-05-30 0:04 ` John Groves
2026-05-22 19:19 ` [PATCH V2 4/7] dax/fsdev: clamp direct_access return to current physical range John Groves
2026-05-27 0:00 ` Dave Jiang
2026-05-30 13:06 ` John Groves
2026-05-22 19:19 ` [PATCH V2 5/7] dax: fix holder_ops race in fs_put_dax() John Groves
2026-05-27 0:16 ` Dave Jiang
2026-05-30 14:02 ` John Groves
2026-05-30 14:32 ` John Groves
2026-05-22 19:19 ` [PATCH V2 6/7] dax: replace exported dax_dev_get() with non-allocating dax_dev_find() John Groves
2026-05-27 0:28 ` Dave Jiang
2026-05-30 14:19 ` John Groves [this message]
2026-05-22 19:19 ` [PATCH V2 7/7] dax: fsdev.c minor formatting cleanup John Groves
2026-05-27 0:31 ` Dave Jiang
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=ahrwrBuEzQaFQ66i@groves.net \
--to=john@groves.net \
--cc=alison.schofield@intel.com \
--cc=brauner@kernel.org \
--cc=dave.jiang@intel.com \
--cc=djbw@kernel.org \
--cc=iweiny@kernel.org \
--cc=jack@suse.cz \
--cc=jgroves@micron.com \
--cc=jic23@kernel.org \
--cc=john@jagalactic.com \
--cc=linux-cxl@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=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