|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6 |
|
| #
f73ca66f |
| 07-Mar-2025 |
Mitchell Levy <[email protected]> |
rust: lockdep: Use Pin for all LockClassKey usages
Reintroduce dynamically-allocated LockClassKeys such that they are automatically (de)registered. Require that all usages of LockClassKeys ensure th
rust: lockdep: Use Pin for all LockClassKey usages
Reintroduce dynamically-allocated LockClassKeys such that they are automatically (de)registered. Require that all usages of LockClassKeys ensure that they are Pin'd.
Currently, only `'static` LockClassKeys are supported, so Pin is redundant. However, it is intended that dynamically-allocated LockClassKeys will eventually be supported, so using Pin from the outset will make that change simpler.
Closes: https://github.com/Rust-for-Linux/linux/issues/1102 Suggested-by: Benno Lossin <[email protected]> Suggested-by: Boqun Feng <[email protected]> Signed-off-by: Mitchell Levy <[email protected]> Signed-off-by: Boqun Feng <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Reviewed-by: Benno Lossin <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
966944f3 |
| 07-Mar-2025 |
Mitchell Levy <[email protected]> |
rust: lockdep: Remove support for dynamically allocated LockClassKeys
Currently, dynamically allocated LockCLassKeys can be used from the Rust side without having them registered. This is a soundnes
rust: lockdep: Remove support for dynamically allocated LockClassKeys
Currently, dynamically allocated LockCLassKeys can be used from the Rust side without having them registered. This is a soundness issue, so remove them.
Fixes: 6ea5aa08857a ("rust: sync: introduce `LockClassKey`") Suggested-by: Alice Ryhl <[email protected]> Signed-off-by: Mitchell Levy <[email protected]> Signed-off-by: Boqun Feng <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Reviewed-by: Benno Lossin <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected]
show more ...
|
|
Revision tags: v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4 |
|
| #
51158207 |
| 19-Dec-2024 |
Wedson Almeida Filho <[email protected]> |
rust: add rcu abstraction
Add a simple abstraction to guard critical code sections with an rcu read lock.
Reviewed-by: Boqun Feng <[email protected]> Signed-off-by: Wedson Almeida Filho <wedsona
rust: add rcu abstraction
Add a simple abstraction to guard critical code sections with an rcu read lock.
Reviewed-by: Boqun Feng <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Danilo Krummrich <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Tested-by: Dirk Behme <[email protected]> Tested-by: Fabien Parent <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
|
Revision tags: v6.13-rc3, v6.13-rc2, v6.13-rc1 |
|
| #
eb5ccb03 |
| 20-Nov-2024 |
Lyude Paul <[email protected]> |
rust: sync: Add SpinLockGuard type alias
A simple helper alias for code that needs to deal with Guard types returned from SpinLocks.
Signed-off-by: Lyude Paul <[email protected]> Reviewed-by: Alice
rust: sync: Add SpinLockGuard type alias
A simple helper alias for code that needs to deal with Guard types returned from SpinLocks.
Signed-off-by: Lyude Paul <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Signed-off-by: Boqun Feng <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
37624dde |
| 20-Nov-2024 |
Lyude Paul <[email protected]> |
rust: sync: Add MutexGuard type alias
A simple helper alias for code that needs to deal with Guard types returned from Mutexes.
Signed-off-by: Lyude Paul <[email protected]> Reviewed-by: Alice Ryhl
rust: sync: Add MutexGuard type alias
A simple helper alias for code that needs to deal with Guard types returned from Mutexes.
Signed-off-by: Lyude Paul <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Signed-off-by: Boqun Feng <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
|
Revision tags: v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5 |
|
| #
8eea62ff |
| 23-Oct-2024 |
Alice Ryhl <[email protected]> |
rust: sync: add global lock support
Add support for creating global variables that are wrapped in a mutex or spinlock.
The implementation here is intended to replace the global mutex workaround fou
rust: sync: add global lock support
Add support for creating global variables that are wrapped in a mutex or spinlock.
The implementation here is intended to replace the global mutex workaround found in the Rust Binder RFC [1]. In both cases, the global lock must be initialized before first use. The macro is unsafe to use for the same reason.
The separate initialization step is required because it is tricky to access the value of __ARCH_SPIN_LOCK_UNLOCKED from Rust. Doing so will require changes to the C side. That change will happen as a follow-up to this patch.
Link: https://lore.kernel.org/rust-for-linux/[email protected]/#Z31drivers:android:context.rs [1] Signed-off-by: Alice Ryhl <[email protected]> Reviewed-by: Boqun Feng <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Simplified a few intra-doc links. Formatted a few comments. Reworded title. - Miguel ] Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
|
Revision tags: v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11 |
|
| #
ac681835 |
| 15-Sep-2024 |
Alice Ryhl <[email protected]> |
rust: file: add abstraction for `poll_table`
The existing `CondVar` abstraction is a wrapper around `wait_queue_head`, but it does not support all use-cases of the C `wait_queue_head` type. To be sp
rust: file: add abstraction for `poll_table`
The existing `CondVar` abstraction is a wrapper around `wait_queue_head`, but it does not support all use-cases of the C `wait_queue_head` type. To be specific, a `CondVar` cannot be registered with a `struct poll_table`. This limitation has the advantage that you do not need to call `synchronize_rcu` when destroying a `CondVar`.
However, we need the ability to register a `poll_table` with a `wait_queue_head` in Rust Binder. To enable this, introduce a type called `PollCondVar`, which is like `CondVar` except that you can register a `poll_table`. We also introduce `PollTable`, which is a safe wrapper around `poll_table` that is intended to be used with `PollCondVar`.
The destructor of `PollCondVar` unconditionally calls `synchronize_rcu` to ensure that the removal of epoll waiters has fully completed before the `wait_queue_head` is destroyed.
That said, `synchronize_rcu` is rather expensive and is not needed in all cases: If we have never registered a `poll_table` with the `wait_queue_head`, then we don't need to call `synchronize_rcu`. (And this is a common case in Binder - not all processes use Binder with epoll.) The current implementation does not account for this, but if we find that it is necessary to improve this, a future patch could store a boolean next to the `wait_queue_head` to keep track of whether a `poll_table` has ever been registered.
Reviewed-by: Benno Lossin <[email protected]> Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Reviewed-by: Trevor Gross <[email protected]> Signed-off-by: Alice Ryhl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
show more ...
|
|
Revision tags: v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4, v6.9-rc3 |
|
| #
7c81aa85 |
| 01-Apr-2024 |
Miguel Ojeda <[email protected]> |
rust: sync: implement `Default` for `LockClassKey`
In the upcoming Rust 1.78.0, Clippy suggests to implement `Default` even when `new()` is `const`, since `Default::default()` may call `const` funct
rust: sync: implement `Default` for `LockClassKey`
In the upcoming Rust 1.78.0, Clippy suggests to implement `Default` even when `new()` is `const`, since `Default::default()` may call `const` functions even if it is not `const` itself [1]:
error: you should consider adding a `Default` implementation for `LockClassKey` --> rust/kernel/sync.rs:31:5 | 31 | / pub const fn new() -> Self { 32 | | Self(Opaque::uninit()) 33 | | } | |_____^
Thus implement it.
Link: https://github.com/rust-lang/rust-clippy/pull/10903 [1] Reviewed-by: Benno Lossin <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Boqun Feng <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
|
Revision tags: v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5, v6.8-rc4, v6.8-rc3 |
|
| #
e283ee23 |
| 29-Jan-2024 |
Alice Ryhl <[email protected]> |
rust: kernel: add reexports for macros
Currently, all macros are reexported with #[macro_export] only, which means that to access `new_work!` from the workqueue, you need to import it from the path
rust: kernel: add reexports for macros
Currently, all macros are reexported with #[macro_export] only, which means that to access `new_work!` from the workqueue, you need to import it from the path `kernel::new_work` instead of importing it from the workqueue module like all other items in the workqueue. By adding reexports of the macros, it becomes possible to import the macros from the correct modules.
It's still possible to import the macros from the root, but I don't think we can do anything about that.
There is no functional change. This is merely a code cleanliness improvement.
Signed-off-by: Alice Ryhl <[email protected]> Reviewed-by: Trevor Gross <[email protected]> Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Tested-by: Boqun Feng <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Removed new `use kernel::prelude::*`s, reworded title. ] Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
|
Revision tags: v6.8-rc2, v6.8-rc1 |
|
| #
e7b9b1ff |
| 08-Jan-2024 |
Alice Ryhl <[email protected]> |
rust: sync: add `CondVar::wait_timeout`
Sleep on a condition variable with a timeout.
This is used by Rust Binder for process freezing. There, we want to sleep until the freeze operation completes,
rust: sync: add `CondVar::wait_timeout`
Sleep on a condition variable with a timeout.
This is used by Rust Binder for process freezing. There, we want to sleep until the freeze operation completes, but we want to be able to abort the process freezing if it doesn't complete within some timeout.
Note that it is not enough to avoid jiffies by introducing a variant of `CondVar::wait_timeout` that takes the timeout in msecs because we need to be able to restart the sleep with the remaining sleep duration if it is interrupted, and if the API takes msecs rather than jiffies, then that would require a conversion roundtrip jiffies->msecs->jiffies that is best avoided.
Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Reviewed-by: Tiago Lam <[email protected]> Reviewed-by: Boqun Feng <[email protected]> Signed-off-by: Alice Ryhl <[email protected]> Reviewed-by: Benno Lossin <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Added `CondVarTimeoutResult` re-export and fixed typo. ] Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
|
Revision tags: v6.7, v6.7-rc8, v6.7-rc7, v6.7-rc6, v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7, v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3, v6.6-rc2, v6.6-rc1, v6.5, v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7, v6.4-rc6, v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3, v6.3-rc7, v6.3-rc6, v6.3-rc5, v6.3-rc4 |
|
| #
19096bce |
| 26-Mar-2023 |
Wedson Almeida Filho <[email protected]> |
rust: sync: introduce `CondVar`
This is the traditional condition variable or monitor synchronisation primitive. It is implemented with C's `wait_queue_head_t`.
It allows users to release a lock an
rust: sync: introduce `CondVar`
This is the traditional condition variable or monitor synchronisation primitive. It is implemented with C's `wait_queue_head_t`.
It allows users to release a lock and go to sleep while guaranteeing that notifications won't be missed. This is achieved by enqueuing a wait entry before releasing the lock.
Cc: Peter Zijlstra <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Will Deacon <[email protected]> Cc: Waiman Long <[email protected]> Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| #
7b1f55e3 |
| 11-Apr-2023 |
Wedson Almeida Filho <[email protected]> |
rust: sync: introduce `LockedBy`
This allows us to have data protected by a lock despite not being wrapped by it. Access is granted by providing evidence that the lock is held by the caller.
Review
rust: sync: introduce `LockedBy`
This allows us to have data protected by a lock despite not being wrapped by it. Access is granted by providing evidence that the lock is held by the caller.
Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Reviewed-by: Benno Lossin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| #
c6d917a4 |
| 19-Apr-2023 |
Wedson Almeida Filho <[email protected]> |
rust: lock: introduce `SpinLock`
This is the `spinlock_t` lock backend and allows Rust code to use the kernel spinlock idiomatically.
Cc: Peter Zijlstra <[email protected]> Cc: Ingo Molnar <ming
rust: lock: introduce `SpinLock`
This is the `spinlock_t` lock backend and allows Rust code to use the kernel spinlock idiomatically.
Cc: Peter Zijlstra <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Will Deacon <[email protected]> Cc: Waiman Long <[email protected]> Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| #
6d20d629 |
| 11-Apr-2023 |
Wedson Almeida Filho <[email protected]> |
rust: lock: introduce `Mutex`
This is the `struct mutex` lock backend and allows Rust code to use the kernel mutex idiomatically.
Cc: Peter Zijlstra <[email protected]> Cc: Ingo Molnar <mingo@re
rust: lock: introduce `Mutex`
This is the `struct mutex` lock backend and allows Rust code to use the kernel mutex idiomatically.
Cc: Peter Zijlstra <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Will Deacon <[email protected]> Cc: Waiman Long <[email protected]> Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| #
76d4bd59 |
| 11-Apr-2023 |
Wedson Almeida Filho <[email protected]> |
rust: sync: introduce `Lock` and `Guard`
They are generic Rust implementations of a lock and a lock guard that contain code that is common to all locks. Different backends will be introduced in subs
rust: sync: introduce `Lock` and `Guard`
They are generic Rust implementations of a lock and a lock guard that contain code that is common to all locks. Different backends will be introduced in subsequent commits.
Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Suggested-by: Gary Guo <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Fixed typo. ] Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| #
6ea5aa08 |
| 11-Apr-2023 |
Wedson Almeida Filho <[email protected]> |
rust: sync: introduce `LockClassKey`
It is a wrapper around C's `lock_class_key`, which is used by the synchronisation primitives that are checked with lockdep. This is in preparation for introducin
rust: sync: introduce `LockClassKey`
It is a wrapper around C's `lock_class_key`, which is used by the synchronisation primitives that are checked with lockdep. This is in preparation for introducing Rust abstractions for these primitives.
Cc: Peter Zijlstra <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Will Deacon <[email protected]> Cc: Waiman Long <[email protected]> Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Co-developed-by: Boqun Feng <[email protected]> Signed-off-by: Boqun Feng <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Reviewed-by: Gary Guo <[email protected]> Reviewed-by: Benno Lossin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
|
Revision tags: v6.3-rc3, v6.3-rc2, v6.3-rc1, v6.2, v6.2-rc8, v6.2-rc7, v6.2-rc6, v6.2-rc5, v6.2-rc4, v6.2-rc3, v6.2-rc2 |
|
| #
70e42ebb |
| 28-Dec-2022 |
Wedson Almeida Filho <[email protected]> |
rust: sync: introduce `UniqueArc`
Since `Arc<T>` does not allow mutating `T` directly (i.e., without inner mutability), it is currently not possible to do some initialisation of `T` post constructio
rust: sync: introduce `UniqueArc`
Since `Arc<T>` does not allow mutating `T` directly (i.e., without inner mutability), it is currently not possible to do some initialisation of `T` post construction but before being shared.
`UniqueArc<T>` addresses this problem essentially being an `Arc<T>` that has a refcount of 1 and is therefore writable. Once initialisation is completed, it can be transitioned (without failure paths) into an `Arc<T>`.
Suggested-by: Gary Guo <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Gary Guo <[email protected]> Reviewed-by: Vincenzo Palazzo <[email protected]> Acked-by: Boqun Feng <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| #
17f67160 |
| 28-Dec-2022 |
Wedson Almeida Filho <[email protected]> |
rust: sync: introduce `ArcBorrow`
This allows us to create references to a ref-counted allocation without double-indirection and that still allow us to increment the refcount to a new `Arc<T>`.
Sig
rust: sync: introduce `ArcBorrow`
This allows us to create references to a ref-counted allocation without double-indirection and that still allow us to increment the refcount to a new `Arc<T>`.
Signed-off-by: Wedson Almeida Filho <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Acked-by: Boqun Feng <[email protected]> Reviewed-by: Gary Guo <[email protected]> Reviewed-by: Vincenzo Palazzo <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| #
9dc04365 |
| 28-Dec-2022 |
Wedson Almeida Filho <[email protected]> |
rust: sync: add `Arc` for ref-counted allocations
This is a basic implementation of `Arc` backed by C's `refcount_t`. It allows Rust code to idiomatically allocate memory that is ref-counted.
Cc: W
rust: sync: add `Arc` for ref-counted allocations
This is a basic implementation of `Arc` backed by C's `refcount_t`. It allows Rust code to idiomatically allocate memory that is ref-counted.
Cc: Will Deacon <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Boqun Feng <[email protected]> Cc: Mark Rutland <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Gary Guo <[email protected]> Reviewed-by: Vincenzo Palazzo <[email protected]> Acked-by: Boqun Feng <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|