| Message ID | 20231109160639.514a2568f1e7.I64fe5615568e87f9ae2d7fb2ac4e5fa96924cb50@changeid (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | debugfs: only clean up d_fsdata for d_is_reg() | expand |
On Thu, 2023-11-09 at 16:06 +0100, Johannes Berg wrote: > > @@ -734,6 +725,11 @@ static void __debugfs_file_removed(struct dentry *dentry) > return; > if (!refcount_dec_and_test(&fsd->active_users)) > wait_for_completion(&fsd->active_users_drained); > + > + /* this no longer matters */ > + dentry->d_fsdata = NULL; > That's not true, and therefore this patch is wrong - full_proxy_release() still happens later. Not sure why I didn't see that originally, even in tests. I'll try again :) johannes
On Thu, Nov 09, 2023 at 04:06:40PM +0100, Johannes Berg wrote: > From: Johannes Berg <johannes.berg@intel.com> > > debugfs_create_automount() can store a function pointer in > d_fsdata, and for directories it may be NULL. The commit > 7c8d469877b1 ("debugfs: add support for more elaborate > ->d_fsdata") ignored that, and while freeing NULL is just > fine, if an automount is ever removed we'd attempt to > kfree() the function pointer. This currently never happens > since the only user (tracing) will never remove the > automount dir. > > Later patches changed the logic here again to store the > real fops, and store the allocation only after a debugfs > file reference is obtained via debugfs_file_get(). > > Remove debugfs_release_dentry() so we won't attempt to > do anything common with the different uses of d_fsdata, > and put the freeing of the allocated data where it's last > possibly used, in __debugfs_file_removed(), which is only > called for regular files. > > Also check in debugfs_file_get() that it gets only called > on regular files, just to make things clearer. > > Signed-off-by: Johannes Berg <johannes.berg@intel.com> > --- > fs/debugfs/file.c | 3 +++ > fs/debugfs/inode.c | 14 +++++--------- > 2 files changed, 8 insertions(+), 9 deletions(-) > > diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c > index 1f971c880dde..1a20c7db8e11 100644 > --- a/fs/debugfs/file.c > +++ b/fs/debugfs/file.c > @@ -84,6 +84,9 @@ int debugfs_file_get(struct dentry *dentry) > struct debugfs_fsdata *fsd; > void *d_fsd; > > + if (WARN_ON(!d_is_reg(dentry))) > + return -EINVAL; Note, the huge majority of Linux systems in the world run with "panic on warn" enabled, so if this is something that could actually happen, please just handle it and return the error, don't throw up a WARN() splat as that will reboot the system, causing you to have grumpy users. thanks, greg k-h
On Fri, 2023-11-10 at 04:56 +0100, Greg Kroah-Hartman wrote: > > > > Also check in debugfs_file_get() that it gets only called > > on regular files, just to make things clearer. > > > > +++ b/fs/debugfs/file.c > > @@ -84,6 +84,9 @@ int debugfs_file_get(struct dentry *dentry) > > struct debugfs_fsdata *fsd; > > void *d_fsd; > > > > + if (WARN_ON(!d_is_reg(dentry))) > > + return -EINVAL; > > Note, the huge majority of Linux systems in the world run with "panic on > warn" enabled, so if this is something that could actually happen, > please just handle it and return the error, don't throw up a WARN() > splat as that will reboot the system, causing you to have grumpy users. > Well, given the use of the d_fsdata, without this check you would get a crash a few lines down in the code because: 1. if you call it with an automount dentry, the pointer is a function pointer and you can't increment a refcount in .text memory 2. if you call it with any other kind of entry other than regular, the pointer is NULL and you can't increment a refcount at just over NULL either I would think this cannot happen in the current kernel now, so the check is more (a) a sign to readers to show the intent of the function, and (b) a help for future users of debugfs to tell them in easier terms when they got it wrong. It just seemed nicer to not crash in weird ways (or corrupt .text if you don't have read-only text, but is that still a thing anywhere?) than crashing with strange errors (especially in 1.). But hey, I can just as well remove it. Note that the other part of the patch here is wrong anyway though, so this patch isn't any good. I posted the replacement here: https://lore.kernel.org/lkml/20231109222251.9e54cb55c700.I64fe5615568e87f9ae2d7fb2ac4e5fa96924cb50@changeid/ johannes
diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c index 1f971c880dde..1a20c7db8e11 100644 --- a/fs/debugfs/file.c +++ b/fs/debugfs/file.c @@ -84,6 +84,9 @@ int debugfs_file_get(struct dentry *dentry) struct debugfs_fsdata *fsd; void *d_fsd; + if (WARN_ON(!d_is_reg(dentry))) + return -EINVAL; + d_fsd = READ_ONCE(dentry->d_fsdata); if (!((unsigned long)d_fsd & DEBUGFS_FSDATA_IS_REAL_FOPS_BIT)) { fsd = d_fsd; diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c index 3f81f73c241a..3f00cd40c81d 100644 --- a/fs/debugfs/inode.c +++ b/fs/debugfs/inode.c @@ -235,14 +235,6 @@ static const struct super_operations debugfs_super_operations = { .free_inode = debugfs_free_inode, }; -static void debugfs_release_dentry(struct dentry *dentry) -{ - void *fsd = dentry->d_fsdata; - - if (!((unsigned long)fsd & DEBUGFS_FSDATA_IS_REAL_FOPS_BIT)) - kfree(dentry->d_fsdata); -} - static struct vfsmount *debugfs_automount(struct path *path) { debugfs_automount_t f; @@ -252,7 +244,6 @@ static struct vfsmount *debugfs_automount(struct path *path) static const struct dentry_operations debugfs_dops = { .d_delete = always_delete_dentry, - .d_release = debugfs_release_dentry, .d_automount = debugfs_automount, }; @@ -734,6 +725,11 @@ static void __debugfs_file_removed(struct dentry *dentry) return; if (!refcount_dec_and_test(&fsd->active_users)) wait_for_completion(&fsd->active_users_drained); + + /* this no longer matters */ + dentry->d_fsdata = NULL; + + kfree(fsd); } static void remove_one(struct dentry *victim)