Re: [PATCH v4 1/9] dax: add fsdev_dax_from_file()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dax: lockdep splat and user-triggerable WARN_ON in fsdev_dax_from_file()
--

commit f952deffb3bddf19404bc61323d8ebb31e8333ad
Author: John Groves <John@Groves.net>
Date:   Thu Oct 8 11:19:52 2026 +0000

    dax: add fsdev_dax_from_file()

This commit adds the fsdev_dax_from_file() helper to get the dax_dev from a
device inode's i_cdev and grab a reference on the private dax inode. It also
makes dax_dev_get() static again, replacing its export with the new helper.

> diff --git a/drivers/dax/fsdev.c b/drivers/dax/fsdev.c
> --- a/drivers/dax/fsdev.c
> +++ b/drivers/dax/fsdev.c

[ ... ]

> @@ -234,6 +234,30 @@ static const struct file_operations fsdev_fops = {
>  	.release = fsdev_release,
>  };
>  
> +/**
> + * fsdev_dax_from_file - get dax_device from an open file
> + * @file: open device file
> + *
> + * Returns a dax_device pointer if @file refers to a fsdev_dax device.
> + * Otherwise return NULL.
> + *
> + * Caller must put_dax() the returned device when done.
> + */
> +struct dax_device *fsdev_dax_from_file(struct file *file)
> +{
> +	struct dax_device *dax_dev;
> +
> +	if (file->f_op != &fsdev_fops)
> +		return NULL;
> +
> +	dax_dev = inode_dax(file_inode(file));
> +	WARN_ON(!dax_alive(dax_dev));
> +	ihold(dax_inode(dax_dev));
> +
> +	return dax_dev;

[Severity: High]
Does this code trigger a lockdep splat when calling dax_alive()?

Looking at dax_alive() in drivers/dax/super.c, it explicitly asserts that
the dax_srcu lock is held:

bool dax_alive(struct dax_device *dax_dev)
{
        lockdep_assert_held(&dax_srcu);
        return test_bit(DAXDEV_ALIVE, &dax_dev->flags);
}

Since fsdev_dax_from_file() does not appear to acquire the dax_srcu lock
before this call, it looks like this will cause a lockdep splat on every
invocation when lockdep is enabled.

Additionally, if an administrator unbinds the driver via sysfs (which
clears DAXDEV_ALIVE), will this WARN_ON become user-triggerable during a
later file lookup? A user-triggerable kernel splat can cause a panic if
panic_on_warn is enabled.

If the device is actually dead, is it safe to proceed to call ihold() and
return the dead device pointer to the caller? Perhaps this path should
return NULL or an error instead of providing a dead device.

> +}
> +EXPORT_SYMBOL_GPL(fsdev_dax_from_file);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261008112004.1899560-1-mszeredi@redhat.com?part=1