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?
