Re: [PATCH] debugfs: warn if file creation failed due to uninitialized debugfs
From: Yohei Kojima
Date: Sat Jun 13 2026 - 05:46:13 EST
Hi Greg,
Thank you for the response.
On Fri, Jun 12, 2026 at 10:14:34AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jun 11, 2026 at 10:50:16PM +0900, Yohei Kojima wrote:
> > Improve debugfs_start_creating() to warn if it was used before debugfs
> > initialization. It silently returned ERR_PTR(-ENOENT) before, but it is
> > hard to find the cause of failure especially if it was called by
> > debugfs_create_dir(), because the document of the function says:
> >
> > > NOTE: it's expected that most callers should _ignore_ the errors returned
> > > by this function. Other debugfs functions handle the fact that the "dentry"
> > > passed to them could be an error and they don't crash in that case.
> > > Drivers should generally work fine even if debugfs fails to init anyway.
> >
> > Signed-off-by: Yohei Kojima <yk@xxxxxxxxx>
> > ---
> > fs/debugfs/inode.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
> > index 4598142355b9..e054e62919ec 100644
> > --- a/fs/debugfs/inode.c
> > +++ b/fs/debugfs/inode.c
> > @@ -368,8 +368,11 @@ static struct dentry *debugfs_start_creating(const char *name,
> > if (!debugfs_enabled)
> > return ERR_PTR(-EPERM);
> >
> > - if (!debugfs_initialized())
> > + if (!debugfs_initialized()) {
> > + pr_err("Unable to create file '%s', debugfs is not initialized yet\n",
> > + name);
> > return ERR_PTR(-ENOENT);
> > + }
>
> While I understand your frustration when adding new code to the kernel
> that would trigger this, does it actually fail on a normal boot today?
No. As far as I tested, no existing code faied there.
> If not, is this really needed?
At least I want. Also, debugfs_start_creating() already warns if the
caller is trying to create a dentry with the same name of an existing
dentry, which also doesn't happen on a normal boot. The warning for
uninitialized debugfs helps developers avoid pitfalls in the same way.
Thanks,
Yohei
>
> thanks,
>
> greg k-h