linux-stable.git/rust/kernel, branch linux-6.5.y

rust: types: make `Opaque` be `!Unpin`

2023-11-08T13:09:04+00:00

[ Upstream commit 0b4e3b6f6b79b1add04008a6ceaaf661107e8902 ]

Adds a `PhantomPinned` field to `Opaque`. This removes the last Rust
guarantee: the assumption that the type `T` can be freely moved. This is
not the case for many types from the C side (e.g. if they contain a
`struct list_head`). This change removes the need to add a
`PhantomPinned` field manually to Rust structs that contain C structs
which must not be moved.

Signed-off-by: Benno Lossin 
Reviewed-by: Gary Guo 
Reviewed-by: Alice Ryhl 
Reviewed-by: Andreas Hindborg 
Link: https://lore.kernel.org/r/20230630150216.109789-1-benno.lossin@proton.me
Signed-off-by: Miguel Ojeda 
Signed-off-by: Sasha Levin

rust: make `UnsafeCell` the outer type in `Opaque`

2023-11-08T13:09:03+00:00

[ Upstream commit 35cad617df2eeef8440a38e82bb2d81ae32ca50d ]

When combining `UnsafeCell` with `MaybeUninit`, it is idiomatic to use
`UnsafeCell` as the outer type. Intuitively, this is because a
`MaybeUninit` might not contain a `T`, but we always want the effect
of the `UnsafeCell`, even if the inner value is uninitialized.

Now, strictly speaking, this doesn't really make a difference. The
compiler will always apply the `UnsafeCell` effect even if the inner
value is uninitialized. But I think we should follow the convention
here.

Signed-off-by: Alice Ryhl 
Reviewed-by: Benno Lossin 
Reviewed-by: Gary Guo 
Reviewed-by: Martin Rodriguez Reboredo 
Link: https://lore.kernel.org/r/20230614115328.2825961-1-aliceryhl@google.com
Signed-off-by: Miguel Ojeda 
Stable-dep-of: 0b4e3b6f6b79 ("rust: types: make `Opaque` be `!Unpin`")
Signed-off-by: Sasha Levin

rust: error: fix the description for `ECHILD`

2023-10-25T10:16:28+00:00

commit 17bfcd6a81535d7d580ddafb6e54806890aaca6c upstream.

A mistake was made and the description of `ECHILD` is wrong (it reuses
the description of `ENOEXEC`). This fixes it to reflect what's in
`errno-base.h`.

Signed-off-by: Wedson Almeida Filho 
Reviewed-by: Martin Rodriguez Reboredo 
Reviewed-by: Trevor Gross 
Reviewed-by: Finn Behrens 
Reviewed-by: Alice Ryhl 
Fixes: 266def2a0f5b ("rust: error: add codes from `errno-base.h`")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230930144958.46051-1-wedsonaf@gmail.com
[ Use the plural, as noticed by Benno. ]
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

rust: delete `ForeignOwnable::borrow_mut`

2023-08-04T15:10:50+00:00

We discovered that the current design of `borrow_mut` is problematic.
This patch removes it until a better solution can be found.

Specifically, the current design gives you access to a `&mut T`, which
lets you change where the `ForeignOwnable` points (e.g., with
`core::mem::swap`). No upcoming user of this API intended to make that
possible, making all of them unsound.

Signed-off-by: Alice Ryhl 
Reviewed-by: Gary Guo 
Reviewed-by: Benno Lossin 
Reviewed-by: Martin Rodriguez Reboredo 
Fixes: 0fc4424d24a2 ("rust: types: introduce `ForeignOwnable`")
Link: https://lore.kernel.org/r/20230706094615.3080784-1-aliceryhl@google.com
Signed-off-by: Miguel Ojeda

rust: allocator: Prevent mis-aligned allocation

2023-08-04T15:10:31+00:00

Currently the rust allocator simply passes the size of the type Layout
to krealloc(), and in theory the alignment requirement from the type
Layout may be larger than the guarantee provided by SLAB, which means
the allocated object is mis-aligned.

Fix this by adjusting the allocation size to the nearest power of two,
which SLAB always guarantees a size-aligned allocation. And because Rust
guarantees that the original size must be a multiple of alignment and
the alignment must be a power of two, then the alignment requirement is
satisfied.

Suggested-by: Vlastimil Babka 
Co-developed-by: "Andreas Hindborg (Samsung)" 
Signed-off-by: "Andreas Hindborg (Samsung)" 
Signed-off-by: Boqun Feng 
Cc: stable@vger.kernel.org # v6.1+
Acked-by: Vlastimil Babka 
Fixes: 247b365dc8dc ("rust: add `kernel` crate")
Link: https://github.com/Rust-for-Linux/linux/issues/974
Link: https://lore.kernel.org/r/20230730012905.643822-2-boqun.feng@gmail.com
[ Applied rewording of comment as discussed in the mailing list. ]
Signed-off-by: Miguel Ojeda

rust: error: `impl Debug` for `Error` with `errname()` integration

2023-06-12T23:24:42+00:00

Integrate the `Error` type with `errname()` by providing a new
`name()` method.

Then, implement `Debug` for the type using the new method.

[ Miguel: under `CONFIG_SYMBOLIC_ERRNAME=n`, `errname()` is a
  `static inline`, so added a helper to support that case,
  like we had in the `rust` branch. Also moved `#include` up
  and reworded commit message for clarity. ]

Co-developed-by: Wedson Almeida Filho 
Signed-off-by: Wedson Almeida Filho 
Co-developed-by: Sven Van Asbroeck 
Signed-off-by: Sven Van Asbroeck 
Signed-off-by: Gary Guo 
Signed-off-by: Alice Ryhl 
Reviewed-by: Martin Rodriguez Reboredo 
Link: https://lore.kernel.org/r/20230531174450.3733220-1-aliceryhl@google.com
Signed-off-by: Miguel Ojeda

rust: task: add `Send` marker to `Task`

2023-05-31T16:53:10+00:00

When a type also implements `Sync`, the meaning of `Send` is just "this
type may be accessed mutably from threads other than the one it is
created on". That's ok for this type.

Signed-off-by: Alice Ryhl 
Reviewed-by: Andreas Hindborg 
Reviewed-by: Gary Guo 
Reviewed-by: Martin Rodriguez Reboredo 
Reviewed-by: Benno Lossin 
Link: https://lore.kernel.org/r/20230531145939.3714886-5-aliceryhl@google.com
Signed-off-by: Miguel Ojeda

rust: specify when `ARef` is thread safe

2023-05-31T16:53:10+00:00

An `ARef` behaves just like the `Arc` when it comes to thread safety, so
we can reuse the thread safety comments from `Arc` here.

This is necessary because without this change, the Rust compiler will
assume that things are not thread safe even though they are.

Signed-off-by: Alice Ryhl 
Reviewed-by: Andreas Hindborg 
Reviewed-by: Boqun Feng 
Reviewed-by: Martin Rodriguez Reboredo 
Reviewed-by: Benno Lossin 
Link: https://lore.kernel.org/r/20230531145939.3714886-4-aliceryhl@google.com
Signed-off-by: Miguel Ojeda

rust: sync: reword the `Arc` safety comment for `Sync`

2023-05-31T16:53:10+00:00

The safety comment on `impl Sync for Arc` references the Send safety
comment. This commit avoids that in case the two comments drift apart in
the future.

Suggested-by: Andreas Hindborg 
Signed-off-by: Alice Ryhl 
Reviewed-by: Andreas Hindborg 
Reviewed-by: Boqun Feng 
Reviewed-by: Martin Rodriguez Reboredo 
Reviewed-by: Benno Lossin 
Link: https://lore.kernel.org/r/20230531145939.3714886-3-aliceryhl@google.com
Signed-off-by: Miguel Ojeda

rust: sync: reword the `Arc` safety comment for `Send`

2023-05-31T16:53:10+00:00

The safety comment on `impl Send for Arc` talks about "directly"
accessing the value, when it really means "accessing the value with a
mutable reference". This commit clarifies that.

Suggested-by: Boqun Feng 
Signed-off-by: Alice Ryhl 
Reviewed-by: Andreas Hindborg 
Reviewed-by: Boqun Feng 
Reviewed-by: Gary Guo 
Reviewed-by: Martin Rodriguez Reboredo 
Reviewed-by: Benno Lossin 
Link: https://lore.kernel.org/r/20230531145939.3714886-2-aliceryhl@google.com
Signed-off-by: Miguel Ojeda