Re: [PATCH] debugfs: warn if file creation failed due to uninitialized debugfs

[Yohei Kojima <yk@y-koj.net>]

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@y-koj.net>
> > ---
> >  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