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

["Danilo Krummrich" <dakr@kernel.org>]

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.

>> This is one of the sources for memory bugs that Rust tries to solve.
>> You can wrap fields into Option types and initialize them later, which would
>> defer pin-init calls for the price of having Option fields around.
>
> I am not denying the need for pinning. Also regarding Option, just thinking
> out loud but if something is optional temporary, maybe needing a new type
> like TempOption, and promote it to a non-option type later, I am not seeing
> that as completely outside the world, if there is a legitimate usecase that
> needs to be Option temporarily, but not later, what's wrong with that? It is
> "Optional" for the timebeing, but not later.

That's what MaybeUninit<T> from the core library already does and promoting it
to T is fundamentally unsafe for obvious reasons.

Drivers should never use that. Having partially initialized structures is a
horrible anti-pattern that we see too often in C code (only for convinience
reasons) causing real memory bugs.

If you run into a case where you want this, 99% of the time you have a design
issue that you should fix instead.

>> 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

> 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?

Or in other words, what are the things you want to do with a KBox<T> in drivers
that you can't do with a Pin<KBox<T>> in a more optimal way?

> that Rust may be able to perform, especially forcefully pinning stuff that
> does not need all to be pinned (except to satisfy paranoia),

Can you please present some examples where it is a major advantage to be able to
move out of a Box in drivers? I think you will have a hard time finding them.

In C code, how often do you move fields out of structures that live within a
kmalloc() allocation?

> thus generating
> suboptimal code gen. Not only does it require redesign and concerns over
> accesses to un-initialized fields,

We're not doing any accesses to uninitialized fields with pin-init, nor do we
encourage them.

> like we saw in the last 2-3 weeks, it also
> forces people into that when maybe there is a chance that underlying
> structures do not need to be pinned at all (for some usecases).

Again, what are those use-cases where you want to be able to move out of a Box
in drivers?