linux-kernel - Re: [PATCH 16/22] rust: pin-init: add `std` and `alloc` support from the user-space version

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: <D88DTO6ZIXMN.26SWTE440RP9K@proton.me>
Date: Wed, 05 Mar 2025 13:55:03 +0000
From: Benno Lossin <benno.lossin@...ton.me>
To: Andreas Hindborg <a.hindborg@...nel.org>
Cc: 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>, Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>, linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org
Subject: Re: [PATCH 16/22] rust: pin-init: add `std` and `alloc` support from the user-space version

On Wed Mar 5, 2025 at 1:22 PM CET, Andreas Hindborg wrote:
> "Benno Lossin" <benno.lossin@...ton.me> writes:
>
>> To synchronize the kernel's version of pin-init with the user-space
>> version, introduce support for `std` and `alloc`. While the kernel uses
>> neither, the user-space version has to support both. Thus include the
>> required `#[cfg]`s and additional code.
>>
>> Signed-off-by: Benno Lossin <benno.lossin@...ton.me>
>> ---
>>  rust/pin-init/src/__internal.rs |  27 ++++++
>>  rust/pin-init/src/alloc.rs      | 158 ++++++++++++++++++++++++++++++++
>>  rust/pin-init/src/lib.rs        |  17 ++--
>>  3 files changed, 196 insertions(+), 6 deletions(-)
>>  create mode 100644 rust/pin-init/src/alloc.rs
>>
>> diff --git a/rust/pin-init/src/__internal.rs b/rust/pin-init/src/__internal.rs
>> index 74086365a18a..27d4a8619c04 100644
>> --- a/rust/pin-init/src/__internal.rs
>> +++ b/rust/pin-init/src/__internal.rs
>> @@ -186,6 +186,33 @@ pub fn init<E>(self: Pin<&mut Self>, init: impl PinInit<T, E>) -> Result<Pin<&mu
>>      }
>>  }
>>
>> +#[test]
>
> I think the kunit support we have in the pipeline will pick this up?

Is that support also enabled for crates outside of the `kernel` crate?
I would argue it shouldn't and then this isn't a problem.

>> +fn stack_init_reuse() {
>> +    use ::std::{borrow::ToOwned, println, string::String};
>> +    use core::pin::pin;
>> +
>> +    #[derive(Debug)]
>> +    struct Foo {
>> +        a: usize,
>> +        b: String,
>> +    }
>> +    let mut slot: Pin<&mut StackInit<Foo>> = pin!(StackInit::uninit());
>> +    let value: Result<Pin<&mut Foo>, core::convert::Infallible> =
>> +        slot.as_mut().init(crate::init!(Foo {
>> +            a: 42,
>> +            b: "Hello".to_owned(),
>> +        }));
>> +    let value = value.unwrap();
>> +    println!("{value:?}");
>> +    let value: Result<Pin<&mut Foo>, core::convert::Infallible> =
>> +        slot.as_mut().init(crate::init!(Foo {
>> +            a: 24,
>> +            b: "world!".to_owned(),
>> +        }));
>> +    let value = value.unwrap();
>> +    println!("{value:?}");
>> +}
>> +
>
> [...]
>
>> diff --git a/rust/pin-init/src/lib.rs b/rust/pin-init/src/lib.rs
>> index 55d8953620f0..1fdca35906a0 100644
>> --- a/rust/pin-init/src/lib.rs
>> +++ b/rust/pin-init/src/lib.rs
>> @@ -204,8 +204,8 @@
>>  //! [structurally pinned fields]:
>>  //!     https://doc.rust-lang.org/std/pin/index.html#pinning-is-structural-for-field
>>  //! [stack]: crate::stack_pin_init
>> -//! [`Arc<T>`]: ../kernel/sync/struct.Arc.html
>> -//! [`Box<T>`]: ../kernel/alloc/struct.KBox.html
>> +//! [`Arc<T>`]: https://doc.rust-lang.org/stable/alloc/sync/struct.Arc.html
>> +//! [`Box<T>`]: https://doc.rust-lang.org/stable/alloc/boxed/struct.Box.html
>
> Now these will render incorrect in the kernel docs, right?

What do you mean by that? The link will resolve to the std versions of
`Arc` and `Box`. But that is also what this crate will support, as it
doesn't know about the kernel's own alloc.

>>  //! [`impl PinInit<Foo>`]: PinInit
>>  //! [`impl PinInit<T, E>`]: PinInit
>>  //! [`impl Init<T, E>`]: Init
>> @@ -239,6 +239,11 @@
>>  #[doc(hidden)]
>>  pub mod macros;
>>
>> +#[cfg(any(feature = "std", feature = "alloc"))]
>> +mod alloc;
>> +#[cfg(any(feature = "std", feature = "alloc"))]
>> +pub use alloc::InPlaceInit;
>
> Do we really need to have this entire file sitting dead in the kernel
> tree? If you are not building the user space version from the kernel
> sources, I don't think we need it here. Even when you want to sync
> between the two repositories, it should be easy to handle an entire file
> being not present on one side.

I do have a script that does the commit porting, you can find it at [1].
So I could easily add that file there. However, I think it also is
important that it's easy to remember which files are synchronized and
which files aren't. At the moment it's very simple, the synchronized
files are:
- README.md
- CONTRIBUTING.md
- src/*
- internal/src/*
- examples/*

If I introduce special cases for files in src, I fear that I might get
confused at some point, making a change that shouldn't be done etc.

I understand your worry about the dead file, but at the same time, I
think it's vital to keep the pattern of synchronized files as simple as
possible.

[1]: https://github.com/Rust-for-Linux/pin-init/commit/7eda8fda7cb48883511db4b5f4fff8d574eef25a

---
Cheers,
Benno