From: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
driver-core@lists.linux.dev
Cc: Yohei Kojima <yk@y-koj.net>,
linux-kernel@vger.kernel.org,
Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Subject: [PATCH] debugfs: don't warn about uninitialized debugfs for an error parent
Date: Thu, 3 Sep 2026 16:51:35 +0500 [thread overview]
Message-ID: <20260903115135.63210-1-mikhail.v.gavrilov@gmail.com> (raw)
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
next reply other threads:[~2026-09-03 11:51 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 11:51 Mikhail Gavrilov [this message]
2026-09-03 16:00 ` [PATCH] debugfs: don't warn about uninitialized debugfs for an error parent Yohei Kojima
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260903115135.63210-1-mikhail.v.gavrilov@gmail.com \
--to=mikhail.v.gavrilov@gmail.com \
--cc=dakr@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=yk@y-koj.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox