[PATCH] debugfs: don't warn about uninitialized debugfs for an error parent

[PATCH] debugfs: don't warn about uninitialized debugfs for an error parent

[Mikhail Gavrilov]

Since commit c3a280ff728a
("debugfs: warn if file creation failed due to uninitialized debugfs")
every boot with CONFIG_REF_TRACKER=y and CONFIG_DEBUG_FS=y prints two
errors before the root filesystem is mounted:

  debugfs: Unable to create file 'net_refcnt@(____ptrval____)',
    debugfs is not initialized yet
  debugfs: Unable to create file 'net_notrefcnt@(____ptrval____)',
    debugfs is not initialized yet

Nothing is actually wrong.  Both files show up under
/sys/kernel/debug/ref_tracker/ once the system is up.  The kernel is
reporting an error for a condition the caller has already accounted for.

net_ns_init() runs directly from start_kernel(), before any initcall, and
calls ref_tracker_dir_init() for init_net's two trackers.  debugfs_init()
is a core_initcall, so debugfs cannot possibly be up at that point.  That
is by design: ref_tracker_dir_debugfs() is documented as safe to call
again later, and net/core/net_namespace.c has a late_initcall() that
re-registers both directories once debugfs exists.

ref_tracker also states that intent to debugfs.  ref_tracker_debug_dir is
initialised to ERR_PTR(-ENOENT) and only gets a real dentry in a
late_initcall, so the early call hands debugfs_create_file() a parent that
is already an error.  debugfs_start_creating() honours that and returns
the parent error, but only after the new pr_err() has fired.

Move the IS_ERR(parent) check above the debugfs_initialized() test.  A
caller passing an error parent is propagating an earlier failure, which is
the pattern debugfs documents and which the warning is not aimed at.  A
caller passing a valid or NULL parent too early - the case the warning was
added for - still gets it.

One behaviour change: an early caller with an error parent now gets
PTR_ERR(parent) back instead of -ENOENT.  All callers of these interfaces
are documented to ignore the return value.

Fixes: c3a280ff728a ("debugfs: warn if file creation failed due to uninitialized debugfs")
Link: https://lore.kernel.org/all/6d1dc775f7d5e754d734907514534054f682bac5.1781171918.git.yk@y-koj.net/
Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
---

Tested on x86_64 (AMD Ryzen 9 7950X), Fedora, v7.3-rc1 plus fixes
(940de590b839), CONFIG_REF_TRACKER=y, CONFIG_DEBUG_FS=y, with KASAN and
lockdep enabled.

Before the patch the two errors appear on every boot, and
/sys/kernel/debug/ref_tracker/ still ends up with one net_refcnt@ and one
net_notrefcnt@ file per network namespace, including the initial one -
the early failure is recovered by the late_initcall() in
net/core/net_namespace.c.

After the patch the errors are gone and the same set of files is created.

#regzbot introduced: c3a280ff728a9039c72cd64ad0b32bc3a28c25b2

 fs/debugfs/inode.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index e054e62919ec..a4d08bd3743b 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -368,6 +368,9 @@ static struct dentry *debugfs_start_creating(const char *name,
 	if (!debugfs_enabled)
 		return ERR_PTR(-EPERM);
 
+	if (IS_ERR(parent))
+		return parent;
+
 	if (!debugfs_initialized()) {
 		pr_err("Unable to create file '%s', debugfs is not initialized yet\n",
 		       name);
@@ -376,9 +379,6 @@ static struct dentry *debugfs_start_creating(const char *name,
 
 	pr_debug("creating file '%s'\n", name);
 
-	if (IS_ERR(parent))
-		return parent;
-
 	error = simple_pin_fs(&debug_fs_type, &debugfs_mount,
 			      &debugfs_mount_count);
 	if (error) {
-- 
2.55.0

Re: [PATCH] debugfs: don't warn about uninitialized debugfs for an error parent

[Yohei Kojima]

On Thu, Sep 03, 2026 at 04:51:35PM +0500, Mikhail Gavrilov wrote:
> Since commit c3a280ff728a
> ("debugfs: warn if file creation failed due to uninitialized debugfs")
> every boot with CONFIG_REF_TRACKER=y and CONFIG_DEBUG_FS=y prints two
> errors before the root filesystem is mounted:
> 
>   debugfs: Unable to create file 'net_refcnt@(____ptrval____)',
>     debugfs is not initialized yet
>   debugfs: Unable to create file 'net_notrefcnt@(____ptrval____)',
>     debugfs is not initialized yet

Ugh... I should've noticed this...

> Move the IS_ERR(parent) check above the debugfs_initialized() test.  A
> caller passing an error parent is propagating an earlier failure, which is
> the pattern debugfs documents and which the warning is not aimed at.  A
> caller passing a valid or NULL parent too early - the case the warning was
> added for - still gets it.
> 
> One behaviour change: an early caller with an error parent now gets
> PTR_ERR(parent) back instead of -ENOENT.  All callers of these interfaces
> are documented to ignore the return value.

The new behavior looks better than the old one as it used to ignore
parent's errno and just returned ERR_PTR(-ENOENT).

> 
> Fixes: c3a280ff728a ("debugfs: warn if file creation failed due to uninitialized debugfs")
> Link: https://lore.kernel.org/all/6d1dc775f7d5e754d734907514534054f682bac5.1781171918.git.yk@y-koj.net/
> Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>

I tested this patch on x86_64 (Intel Core i7-14700K), Gentoo, v7.3-rc1
(940de590b839), CONFIG_REF_TRACKER=y, CONFIG_DEBUG_FS=y, with KASAN and
lockdep enabled.

  $ diff -u before_patch after_patch 
  --- before_patch        2026-09-03 23:46:02.856774818 +0900
  +++ after_patch 2026-09-03 23:46:09.990259686 +0900
  @@ -1,8 +1,6 @@
   Yama: becoming mindful.
   SELinux:  Initializing.
  -debugfs: Unable to create file 'net_refcnt@(____ptrval____)', debugfs is not initialized yet
   stackdepot: allocating hash table of 131072 entries via kvcalloc
   stackdepot: allocating space for 8192 stack pools via kvcalloc
  -debugfs: Unable to create file 'net_notrefcnt@(____ptrval____)', debugfs is not initialized yet
   Mount-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
   Mountpoint-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)

Tested-by: Yohei Kojima <yk@y-koj.net>

Thank you for reporting and fixing this during rc!

Yohei