linux-kernel - Re: [PATCH v5 02/12] gpu: nova-core: move GSP boot code to a dedicated method

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250913230254.GA1568515@joelbox2>
Date: Sat, 13 Sep 2025 19:02:54 -0400
From: Joel Fernandes <joelagnelf@...dia.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: Alexandre Courbot <acourbot@...dia.com>,
	Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <lossin@...nel.org>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Maxime Ripard <mripard@...nel.org>,
	Thomas Zimmermann <tzimmermann@...e.de>,
	John Hubbard <jhubbard@...dia.com>,
	Alistair Popple <apopple@...dia.com>, Timur Tabi <ttabi@...dia.com>,
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
	nouveau@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v5 02/12] gpu: nova-core: move GSP boot code to a
 dedicated method

Hi Danilo,

On Sat, Sep 13, 2025 at 09:53:16PM +0200, Danilo Krummrich wrote:
> On Sat Sep 13, 2025 at 7:13 PM CEST, Joel Fernandes wrote:
> > On Sat, Sep 13, 2025 at 03:30:31PM +0200, Danilo Krummrich wrote:
> >> On Sat Sep 13, 2025 at 3:02 AM CEST, Joel Fernandes wrote:
> >> > Any chance we can initialize the locks later? We don't need locking until
> >> > after the boot process is completed, and if there's a way we can dynamically
> >> > "pin", where we hypothetically pin after the boot process completed, that
> >> > might also work. Though I am not sure if that's something possible in
> >> > Rust/rust4linux or if it makes sense.
> >> 
> >> We can't partially initialize structures and then rely on accessing initialized
> >> data only.
> >
> > Yet, that is exactly what the pin initialization sequence block does? The
> > whole structure is not initialized yet you need access to already initialized
> > fields.
> 
> No, having a reference to a partially initialized structure is UB. But of course
> you can have a reference to already initialized fields within a not yet fully
> initialized structure.

Fair enough.

> >> However, we should never do such things. If there's the necessity to do
> >> something like that, it indicates a design issue.
> >> 
> >> In this case, there's no problem, we can use pin-init without any issues right
> >> away, and should do so.
> >> 
> >> pin-init is going to be an essential part of *every* Rust driver given that a
> >> lot of the C infrastruture that we abstract requires pinned initialization, such
> >> as locks and other synchronization primitives.
> >
> > To be honest, the pinning concept seems like an after thought for such a
> > fundamental thing that we need, requiring additional macros, and bandaids on
> > top of the language itself, to make it work for the kernel. I am not alone in
> > that opinion. This should be first-class in a (systems) language, built into
> > the language itself? I am talking about the whole pin initialization,
> > accessing fields dances, etc.
> 
> Yes, that's exactly why people (Benno) are already working on making this a
> language feature (here's a first step in this direction [1]).
> 
> Benno should have more details on this.
> 
> [1] https://github.com/rust-lang/rust/pull/146307

Ack, thanks for the pointer. I will study it further.

> > Also I am concerned that overusage of pinning defeats a lot of optimizations
> 
> pin-init does the oposite it allows us to use a single memory allocation where
> otherwise you would need multiple.
> 
> Can you please show some optimizations that can not be done in drivers due to
> pin-init for dynamic allocations?

Aren't the vector resizing issues an example? The debugfs discussions for
example. You can't resize pinned vectors without boxing each element which is
suboptimal due to requiring additional allocations?

But agreed, it appears maybe this isn't as much an issue as I thought. I
think I confused prevention of stuff allocated on the stack from moving, with
pinning. I think the only other reason I can see, is to not to reduce code
readability if pinning is really not needed and if it is used, to add
appropriate code comments.

Thank you for taking the time to explain this to me. I really appreciate it,
and please let me know if I missed something!

 - Joel