From: Vladislav Zaharov <vladazaharova2018@gmail.com>
To: dakr@kernel.org, jhubbard@nvidia.com
Cc: acourbot@nvidia.com, aliceryhl@google.com, ttabi@nvidia.com,
gary@garyguo.net, nova-gpu@lists.linux.dev,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org,
Vladislav Zaharov <vladazaharova2018@gmail.com>
Subject: [PATCH v3 1/3] gpu: nova-core: build the debugfs guard before registering the driver
Date: Sat, 12 Sep 2026 14:18:40 +0700 [thread overview]
Message-ID: <20260912071842.622696-2-vladazaharova2018@gmail.com> (raw)
In-Reply-To: <20260912071842.622696-1-vladazaharova2018@gmail.com>
init() creates the debugfs root, hands it to a static, and leaves it to
DebugfsRootGuard to clear that static once the module goes away.
try_pin_init! builds fields in the order they are written, and an
initializer that fails drops only what it has already built. The guard
is written after the Registration, so a registration that fails leaves
it unbuilt and its drop never runs. Statics are not dropped either, and
the module is unloaded right after, so the "nova-core" directory outlives
everything that could remove it.
The next load then finds the name taken: debugfs_create_dir() returns
-EEXIST, which Entry keeps as it would any other pointer, and every
debugfs file of the driver silently fails to appear until the machine is
rebooted.
Build the guard first. Drops still run in declaration order, so the
driver is still unregistered before the guard clears the static.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Vladislav Zaharov <vladazaharova2018@gmail.com>
---
drivers/gpu/nova-core/nova_core.rs | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/nova-core/nova_core.rs b/drivers/gpu/nova-core/nova_core.rs
index 1133c6ce5c55..11fe1d2858a9 100644
--- a/drivers/gpu/nova-core/nova_core.rs
+++ b/drivers/gpu/nova-core/nova_core.rs
@@ -47,7 +47,8 @@ fn drop(&mut self) {
#[pin_data]
struct NovaCoreModule {
// Fields are dropped in declaration order, so `_driver` is dropped first,
- // then `_debugfs_guard` clears `DEBUGFS_ROOT`.
+ // then `_debugfs_guard` clears `DEBUGFS_ROOT`. They are initialized the
+ // other way round, see `init()`.
#[pin]
_driver: Registration<pci::Adapter<driver::NovaCoreDriver>>,
_debugfs_guard: DebugfsRootGuard,
@@ -61,9 +62,14 @@ fn init(module: &'static kernel::ThisModule) -> impl PinInit<Self, Error> {
// cannot be any concurrent access to `DEBUGFS_ROOT`.
unsafe { DEBUGFS_ROOT = Some(dir) };
+ // Fields are initialized in the order written here, and an initializer that fails drops
+ // what it has already built, so the guard goes first: should registration fail, its drop
+ // still takes `DEBUGFS_ROOT` down with it. Nothing would otherwise, as statics are never
+ // dropped and the module is unloaded right away, leaving a directory behind that the
+ // next load cannot create again.
try_pin_init!(Self {
- _driver <- Registration::new(MODULE_NAME, module),
_debugfs_guard: DebugfsRootGuard,
+ _driver <- Registration::new(MODULE_NAME, module),
})
}
}
--
2.55.0
next prev parent reply other threads:[~2026-09-12 7:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-12 7:18 [PATCH v3 0/3] gpu: nova-core: retain the GSP-RM log buffers Vladislav Zaharov
2026-09-12 7:18 ` Vladislav Zaharov [this message]
2026-09-12 7:18 ` [PATCH v3 2/3] gpu: nova-core: gsp: retain the GSP-RM log buffers after unbind Vladislav Zaharov
2026-09-12 17:55 ` Gary Guo
2026-09-12 7:18 ` [PATCH v3 3/3] Documentation: nova: remove completed GSP log buffer task Vladislav Zaharov
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=20260912071842.622696-2-vladazaharova2018@gmail.com \
--to=vladazaharova2018@gmail.com \
--cc=acourbot@nvidia.com \
--cc=aliceryhl@google.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nova-gpu@lists.linux.dev \
--cc=ttabi@nvidia.com \
/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