From: "Danilo Krummrich" <dakr@kernel.org>
To: "Alexandre Courbot" <acourbot@nvidia.com>
Cc: "Vladislav Zaharov" <vladazaharova2018@gmail.com>,
<jhubbard@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>
Subject: Re: [PATCH v6 1/3] gpu: nova-core: move the debugfs root into the module data
Date: Sat, 07 Nov 2026 14:14:37 +0100 [thread overview]
Message-ID: <DMP087IP6EDP.2QB7783SVNV2T@kernel.org> (raw)
In-Reply-To: <DMOS00OZYWU5.2SUZRN37DEH87@nvidia.com>
On Sat Nov 7, 2026 at 7:47 AM CET, Alexandre Courbot wrote:
> On Thu Oct 15, 2026 at 12:45 AM JST, Vladislav Zaharov wrote:
> Another thing: since this is declaring now a proper interface, can you
> move `DebugfsData`, `debugfs_data` and `DEBUGFS_DATA` into a sub-module,
> say `debugfs.rs`?
I think that makes sense.
>> impl InPlaceModule for NovaCoreModule {
>> fn init(module: &'static kernel::ThisModule) -> impl PinInit<Self, Error> {
>> - let dir = debugfs::Dir::new(c"nova-core");
>> -
>> - // SAFETY: We are the only driver code running during init, so there
>> - // cannot be any concurrent access to `DEBUGFS_ROOT`.
>> - unsafe { DEBUGFS_ROOT = Some(dir) };
>> -
>> try_pin_init!(Self {
>> + _debugfs <- DebugfsData::new(),
>> + _: {
>> + // SAFETY: Nothing reads `DEBUGFS_DATA` before a device is bound, which cannot
>> + // happen until the driver is registered below. What it points at is dropped only
>> + // once the driver is unregistered, so it is valid for as long as any device is
>> + // bound, and nothing reads it outside of that.
>> + unsafe { DEBUGFS_DATA = &*_debugfs };
>> + },
>
> Let's move this initialization into `DebugfsData::new`, using
> `pin_chain`:
>
> /// Returns an initializer that creates the shared debugfs data.
> ///
> /// # Safety
> ///
> /// The returned initializer must be run exactly once before the driver is registered. The
> /// initialized [`DebugfsData`] must outlive the driver registration.
> pub(super) unsafe fn new() -> impl PinInit<Self> {
> pin_init!(Self {
> root: debugfs::Dir::new(c"nova-core"),
> })
> .pin_chain(|debugfs| {
> // SAFETY: Per the method's safety block, the driver is not registered yet, meaning that
> // no device can be probed and thus nothing can access `DEBUGFS_DATA` concurrently.
> //
> // INVARIANT: Per the method's safety block, `DEBUGFS_DATA` is written before the driver
> // is registered and points to a valid instance of `DebugfsData`, which is pinned
> // and dropped after the driver is unregistered.
> unsafe { DEBUGFS_DATA = &*debugfs };
> Ok(())
> })
> }
>
> That way, the burden of enforcing the invariants for `DEBUGFS_DATA`
> relies exclusively on `new` (and we made it unsafe to force the caller
> to do that).
Actually, I would leave that part as is.
Eventually we'll have registration data for driver registrations to share module
data. Once we have that, we'd need to change DebugfsData::new() again and move
that part bnack into NovaCoreModule::init().
Besides that, DebugfsData has nothing to do with the current limitation of
publishing module data to driver registrations; the module code seems like the
correct place to deal with this.
next prev parent reply other threads:[~2026-11-07 13:14 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 15:45 [PATCH v6 0/3] gpu: nova-core: retain the GSP-RM log buffers Vladislav Zaharov
2026-10-14 15:45 ` [PATCH v6 1/3] gpu: nova-core: move the debugfs root into the module data Vladislav Zaharov
2026-11-07 1:23 ` Alexandre Courbot
2026-11-07 6:47 ` Alexandre Courbot
2026-11-07 13:14 ` Danilo Krummrich [this message]
2026-11-07 13:32 ` Alexandre Courbot
2026-11-07 23:18 ` Danilo Krummrich
2026-10-14 15:45 ` [PATCH v6 2/3] gpu: nova-core: gsp: retain the GSP-RM log buffers after unbind Vladislav Zaharov
2026-11-07 1:26 ` Alexandre Courbot
2026-10-14 15:45 ` [PATCH v6 3/3] Documentation: nova: remove completed GSP log buffer task Vladislav Zaharov
2026-11-06 20:51 ` [PATCH v6 0/3] gpu: nova-core: retain the GSP-RM log buffers Timur Tabi
2026-11-06 22:52 ` Danilo Krummrich
2026-11-06 23:15 ` John Hubbard
2026-11-06 23:08 ` Alexandre Courbot
2026-11-06 23:15 ` Alexandre Courbot
2026-11-07 0:39 ` John Hubbard
2026-11-07 1:38 ` Danilo Krummrich
2026-11-07 1:40 ` John Hubbard
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=DMP087IP6EDP.2QB7783SVNV2T@kernel.org \
--to=dakr@kernel.org \
--cc=acourbot@nvidia.com \
--cc=aliceryhl@google.com \
--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 \
--cc=vladazaharova2018@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.