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

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?

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

On Sun Sep 14, 2025 at 1:02 AM CEST, Joel Fernandes
wrote:
> 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:
>> >> 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
That's the link to the implementation PR, if you know the internals of
the compiler it sure is useful, but if not, only the first comment is :)
> Ack, thanks for the pointer. I will study it further.
I'd recommend looking at these links, as they talk more about the design
& not the compiler implementation:

* https://github.com/rust-lang/rust/issues/145383
* https://hackmd.io/@rust-lang-team/S1I1aEc_lx
* https://rust-lang.github.io/rust-project-goals/2025h2/field-projections.html

For pin specifically, there also is the pin-ergonomics effort:

* https://github.com/rust-lang/rust/issues/130494

Which is less general than the field projections that I'm working on,
but more specific to pin & tries to make it more compiler internal.

Now for pinned initialization, Alice has a project goal & proposal:

*
https://rust-lang.github.io/rust-project-goals/2025h2/in-place-initialization.html
* https://hackmd.io/%40aliceryhl/BJutRcPblx

This proposal was heavily influenced by pin-init & we're actively
working together with others from the Rust community in getting this to
a language feature.

It's a pretty complicated feature and people just worked around it
before, which you can do when starting from the ground-up (similar to
field projections).
>> > 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?
Yes, but that's not really an optimization, is it? In the non-pinned
case, the compiler wouldn't remove the allocation. You can select less
efficient algorithms, since the objects aren't allowed to move, but that
same restriction also applies in C.

---
Cheers,
Benno