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 <[email protected]> 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/[email protected]?part=1
