Move the definitions of `ARef` and `AlwaysRefCounted` from `types.rs`
to a new file `sync/aref.rs`. Define the corresponding `aref` module
under `rust/kernel/sync.rs`. These types are better grouped in `sync`.
To avoid breaking existing imports, they are re-exported from `types.rs`.
Drop unused imports `mem::ManuallyDrop`, `ptr::NonNull` from `types.rs`,
they are now only used in `sync/aref.rs`, where they are already imported.
Suggested-by: Benno Lossin <lossin@kernel.org>
Link: https://github.com/Rust-for-Linux/linux/issues/1173
Signed-off-by: Shankari Anand <shankari.ak0208@gmail.com>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Link: https://lore.kernel.org/r/20250715110423.334744-1-shankari.ak0208@gmail.com
[ Added missing `///`. Changed module title. Reworded slightly. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
The safety comment mentions lockdep -- which from a Rust perspective
isn't important -- and doesn't mention the real reason for why it's
sound to create `LockClassKey` as uninitialized memory.
Signed-off-by: Benno Lossin <lossin@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20250520231714.323931-1-lossin@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
This enum is not used. Additionally, using it would result in poor
ergonomics, because in order to do any operation on a value it has to be
matched first. Our version of `Either` also doesn't provide any helper
methods making it even more difficult to use.
The alternative of creating a custom enum for the concrete use-case also
is much better for ergonomics. As one can provide functions on the type
directly and users don't need to match the value manually.
Signed-off-by: Benno Lossin <lossin@kernel.org>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/r/20250519124304.79237-1-lossin@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Prepare for `core::ffi::CStr` taking the place of `kernel::str::CStr` by
avoiding methods that only exist on the latter.
Also avoid `Deref<Target=BStr> for CStr` as that impl doesn't exist on
`core::ffi::CStr`.
Link: https://github.com/Rust-for-Linux/linux/issues/1075
Signed-off-by: Tamir Duberstein <tamird@gmail.com>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20250704-core-cstr-prepare-v1-6-a91524037783@gmail.com
[ Reworded title. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Prepare for replacing `CStr` with `core::ffi::CStr` by soft-deprecating
methods which don't exist on `core::ffi::CStr`.
We could keep `as_bytes{,_with_nul}` through an extension trait but
seeing as we have to introduce `as_char_ptr_in_const_context` as a free
function, we may as well introduce `to_bytes{,_with_nul}` here to allow
downstream code to migrate in one cycle rather than two.
Link: https://github.com/Rust-for-Linux/linux/issues/1075
Signed-off-by: Tamir Duberstein <tamird@gmail.com>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20250704-core-cstr-prepare-v1-5-a91524037783@gmail.com
[ Reworded title. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
`core::ffi::*` is in the prelude, which is imported here.
Signed-off-by: Tamir Duberstein <tamird@gmail.com>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20250704-core-cstr-prepare-v1-4-a91524037783@gmail.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reduce coupling to implementation details of the formatting machinery by
avoiding direct use for `core`'s formatting traits and macros.
Signed-off-by: Tamir Duberstein <tamird@gmail.com>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20250704-core-cstr-prepare-v1-3-a91524037783@gmail.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
`kernel::fmt` is a facade over `core::fmt` that can be used downstream,
allowing future changes to the formatting machinery to be contained
within the kernel crate without downstream code needing to be modified.
Signed-off-by: Tamir Duberstein <tamird@gmail.com>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20250704-core-cstr-prepare-v1-2-a91524037783@gmail.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Rather than export a macro that delegates to `core::format_args`, simply
re-export `core::format_args` as `fmt` from the prelude. This exposes
clippy warnings which were previously obscured by this macro, such as:
warning: variables can be used directly in the `format!` string
--> ../drivers/cpufreq/rcpufreq_dt.rs:21:43
|
21 | let prop_name = CString::try_from_fmt(fmt!("{}-supply", name)).ok()?;
| ^^^^^^^^^^^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args
= note: `-W clippy::uninlined-format-args` implied by `-W clippy::all`
= help: to override `-W clippy::all` add `#[allow(clippy::uninlined_format_args)]`
help: change this to
|
21 - let prop_name = CString::try_from_fmt(fmt!("{}-supply", name)).ok()?;
21 + let prop_name = CString::try_from_fmt(fmt!("{name}-supply")).ok()?;
|
Thus fix them in the same commit. This could possibly be fixed in two
stages, but the diff is small enough (outside of kernel/str.rs) that I
hope it can be taken in a single commit.
Signed-off-by: Tamir Duberstein <tamird@gmail.com>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/r/20250704-core-cstr-prepare-v1-1-a91524037783@gmail.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
`ListLinks` does not take a `T` generic parameter, unlike
`ListLinksSelfPtr`.
Thus fix it, which makes it also consistent with the rest of the links
in the file.
Fixes: 40c5329459 ("rust: list: add macro for implementing ListItem")
Reviewed-by: Tamir Duberstein <tamird@gmail.com>
Link: https://lore.kernel.org/r/20250719232500.822313-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
In light of bindgen being unable to generate bindings for macros, and
owing to the widespread use of these macros in drivers, manually define
the bit and genmask C macros in Rust.
The *_checked version of the functions provide runtime checking while
the const version performs compile-time assertions on the arguments via
the build_assert!() macro.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/r/20250714-topics-tyr-genmask2-v9-1-9e6422cbadb6@collabora.com
[ `expect`ed Clippy warning in doctests, hid single `use`, grouped
examples. Reworded title. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Replace `ListLinksSelfPtr::LIST_LINKS_SELF_PTR_OFFSET` with `unsafe fn
raw_get_self_ptr` which returns a pointer to the field rather than
requiring the caller to do pointer arithmetic.
Implement `HasListLinks::raw_get_list_links` in `impl_has_list_links!`,
narrowing the interface of `HasListLinks` and replacing pointer
arithmetic with `container_of!`.
Modify `impl_list_item` to also invoke `impl_has_list_links!` or
`impl_has_list_links_self_ptr!`. This is necessary to allow
`impl_list_item` to see more of the tokens used by
`impl_has_list_links{,_self_ptr}!`.
A similar API change was discussed on the hrtimer series[1].
Link: https://lore.kernel.org/all/20250224-hrtimer-v3-v6-12-rc2-v9-1-5bd3bf0ce6cc@kernel.org/ [1]
Tested-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Tamir Duberstein <tamird@gmail.com>
Link: https://lore.kernel.org/r/20250709-list-no-offset-v4-6-a429e75840a9@gmail.com
[ Fixed broken intra-doc links. Used the renamed
`Opaque::cast_into`. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
There's a comprehensive example in `rust/kernel/list.rs` but it doesn't
exercise the `using ListLinksSelfPtr` variant nor the generic cases. Add
that here. Generalize `impl_has_list_links_self_ptr` to handle nested
fields in the same manner as `impl_has_list_links`.
Tested-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Tamir Duberstein <tamird@gmail.com>
Link: https://lore.kernel.org/r/20250709-list-no-offset-v4-5-a429e75840a9@gmail.com
[ Fixed Rust < 1.82 build by enabling the `offset_of_nested`
feature. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Use a fully qualified path rooted at `$crate` rather than relying on
imports in the invoking scope.
Tested-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Tamir Duberstein <tamird@gmail.com>
Link: https://lore.kernel.org/r/20250709-list-no-offset-v4-4-a429e75840a9@gmail.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Refer to the self parameter of `impl_list_item!` by the same name used
in `impl_has_list_links{,_self_ptr}!`.
Reviewed-by: Christian Schrefl <chrisi.schrefl@gmail.com>
Tested-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Tamir Duberstein <tamird@gmail.com>
Link: https://lore.kernel.org/r/20250709-list-no-offset-v4-3-a429e75840a9@gmail.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Refer to the type parameters of `impl_has_list_links{,_self_ptr}!` by
the same name used in `impl_list_item!`. Capture type parameters of
`impl_list_item!` as `tt` using `{}` to match the style of all other
macros that work with generics.
Reviewed-by: Christian Schrefl <chrisi.schrefl@gmail.com>
Tested-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Tamir Duberstein <tamird@gmail.com>
Link: https://lore.kernel.org/r/20250709-list-no-offset-v4-2-a429e75840a9@gmail.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Avoid manually capturing generics; use `ty` to capture the whole type
instead.
Reviewed-by: Christian Schrefl <chrisi.schrefl@gmail.com>
Tested-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Tamir Duberstein <tamird@gmail.com>
Link: https://lore.kernel.org/r/20250709-list-no-offset-v4-1-a429e75840a9@gmail.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
When we renamed `Opaque::raw_get` to `cast_into`, there was one
replacement that was not supposed to be there.
It does not cause an issue so far because it is inside a macro rule (the
`ListLinksSelfPtr` one) that is unused so far. However, it will start
to be used soon.
Thus fix it now.
Fixes: 64fb810bce ("rust: types: rename Opaque::raw_get to cast_into")
Reviewed-by: Tamir Duberstein <tamird@gmail.com>
Link: https://lore.kernel.org/r/20250719183649.596051-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
While rebasing rvkms I noticed that timers I was setting seemed to have
pretty random timer values that amounted slightly over 2x the time value I
set each time. After a lot of debugging, I finally managed to figure out
why: it seems that since we moved to Instant and Delta, we mistakenly
began passing the clocksource ID to hrtimer_start_range_ns, when we should
be passing the timer mode instead. Presumably, this works fine for simple
relative timers - but immediately breaks on other types of timers.
So, fix this by passing the ID for the timer mode instead.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Acked-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Fixes: e0c0ab04f6 ("rust: time: Make HasHrTimer generic over HrTimerMode")
Link: https://lore.kernel.org/r/20250710225129.670051-1-lyude@redhat.com
[ Removed cast, applied `rustfmt`, fixed `Fixes:` tag. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJKBAABCAA0FiEEEsH5R1a/fCoV1sAS4bgaPnkoY3cFAmhrd38WHGEuaGluZGJv
cmdAa2VybmVsLm9yZwAKCRDhuBo+eShjd0CsD/9qKvg1sVajmgcuksUbxakjDOK+
xg5ySpv/a+aIkoR9sWAcNCZY0VUZPkO3+l5otTV3f6ehovPJkuvm9eBD6NepwAf+
+lBO6TSaEGzwyGS/m8LT1vjcx5FAjEX/rT1bI5jjROUgfEnyMYtL11e/X3N0Heja
Gc2VQhUabEgS1Vvf9XGKDTbBZJYyL4ZPZGRiUz2ZGwReL0RD9swbzUaoXLFLqH8w
g4vHa+nVdMJGaTD5tAc6Em9hAWf8BkVbUNRzjqNP4sF3H3BB1CZg42MiR4Xa0teN
SVAEqza7eBSHeUfmWFodkj5H5lGTOQjDK/OzVEfp0HyZT929CcG+4chieWPvc7aT
KlBF4SxtXGHyyEfctmxuAEJwbdPobQQyGjCdEW3L0SWVpGRo/j6SesAyB3ldNsig
JKKeqw9BGmJQaEgjUH81iPmP9uvo/qrzPBewNE1abS17DPowEcEeWmn7NhXLx5hq
Y6HsrcPoeotvW71ZiwrACmZaFG4V2LxJLEiUyn9Rl896BMZJCShQbBciZzI6nfLF
EAGEV1t4sCW158LDAMjCxZdLMcXzj0fBMTyLobMPK6KFwXjDaOlxjK+tT6eV9W1O
7lLkYYeZRWFjijnpwn1tE4x56je29sAezJWDCIZb5g6OUh/HgjEMukTLI64W+fY1
0uOhZ4lTtwo1j6b/1Q==
=iwdh
-----END PGP SIGNATURE-----
Merge tag 'rust-timekeeping-for-v6.17' of https://github.com/Rust-for-Linux/linux into rust-next
Pull timekeeping updates from Andreas Hindborg:
- Make 'Instant' generic over clock source. This allows the compiler to
assert that arithmetic expressions involving the 'Instant' use
'Instants' based on the same clock source.
- Make 'HrTimer' generic over the timer mode. 'HrTimer' timers take a
'Duration' or an 'Instant' when setting the expiry time, depending on
the timer mode. With this change, the compiler can check the type
matches the timer mode.
- Add an abstraction for 'fsleep'. 'fsleep' is a flexible sleep
function that will select an appropriate sleep method depending on
the requested sleep time.
- Avoid 64-bit divisions on 32-bit hardware when calculating
timestamps.
- Seal the 'HrTimerMode' trait. This prevents users of the
'HrTimerMode' from implementing the trait on their own types.
* tag 'rust-timekeeping-for-v6.17' of https://github.com/Rust-for-Linux/linux:
rust: time: Add wrapper for fsleep() function
rust: time: Seal the HrTimerMode trait
rust: time: Remove Ktime in hrtimer
rust: time: Make HasHrTimer generic over HrTimerMode
rust: time: Add HrTimerExpires trait
rust: time: Replace HrTimerMode enum with trait-based mode types
rust: time: Add ktime_get() to ClockSource trait
rust: time: Make Instant generic over ClockSource
rust: time: Replace ClockId enum with ClockSource trait
rust: time: Avoid 64-bit integer division on 32-bit architectures
Box:
- Implement Borrow / BorrowMut for Box<T, A>.
Vec:
- Implement Default for Vec<T, A>.
- Implement Borrow / BorrowMut for Vec<T, A>.
DMA:
- Clarify wording and be consistent in 'coherent' nomenclature.
- Convert the read!() / write!() macros to return a Result.
- Add as_slice() / write() methods in CoherentAllocation.
- Fix doc-comment of dma_handle().
- Expose count() and size() in CoherentAllocation and add the
corresponding type invariants.
- Implement CoherentAllocation::dma_handle_with_offset().
- Require mutable reference for as_slice_mut() and write().
- Add Vlastimil Babka, Liam R. Howlett, Uladzislau Rezki and Lorenzo Stoakes
as reviewers (thanks everyone).
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS2q/xV6QjXAdC7k+1FlHeO1qrKLgUCaHZWlAAKCRBFlHeO1qrK
LgBrAQDgp1+5ocMJKJDgBtCXpRCe2F9OBz9L7CY1EzSRz2JHTAD/YZ5D1DeSi1l8
U+tqG9+5i8twB3PR/TC4d7+GaBfTcQQ=
=LaOk
-----END PGP SIGNATURE-----
Merge tag 'alloc-next-v6.17-2025-07-15' of https://github.com/Rust-for-Linux/linux into rust-next
Pull alloc and DMA updates from Danilo Krummrich:
Box:
- Implement Borrow / BorrowMut for Box<T, A>.
Vec:
- Implement Default for Vec<T, A>.
- Implement Borrow / BorrowMut for Vec<T, A>.
DMA:
- Clarify wording and be consistent in 'coherent' nomenclature.
- Convert the read!() / write!() macros to return a Result.
- Add as_slice() / write() methods in CoherentAllocation.
- Fix doc-comment of dma_handle().
- Expose count() and size() in CoherentAllocation and add the
corresponding type invariants.
- Implement CoherentAllocation::dma_handle_with_offset().
- Require mutable reference for as_slice_mut() and write().
MAINTAINERS:
- Add Vlastimil Babka, Liam R. Howlett, Uladzislau Rezki and Lorenzo
Stoakes as reviewers (thanks everyone).
* tag 'alloc-next-v6.17-2025-07-15' of https://github.com/Rust-for-Linux/linux:
MAINTAINERS: add mm folks as reviewers to rust alloc
rust: dma: require mutable reference for as_slice_mut() and write()
rust: dma: add dma_handle_with_offset method to CoherentAllocation
rust: dma: expose the count and size of CoherentAllocation
rust: dma: fix doc-comment of dma_handle()
rust: dma: add as_slice/write functions for CoherentAllocation
rust: dma: convert the read/write macros to return Result
rust: dma: clarify wording and be consistent in `coherent` nomenclature
rust: alloc: implement `Borrow` and `BorrowMut` for `KBox`
rust: alloc: implement `Borrow` and `BorrowMut` for `Vec`
rust: vec: impl Default for Vec with any allocator
This patch is being sent for use in the various Rust GPU drivers that
are under development. It provides the additional feature of work items
that are executed after a delay.
The design of the existing workqueue is rather extensible, as most of
the logic is reused for delayed work items even though a different work
item type is required. The new logic consists of:
* A new DelayedWork struct that wraps struct delayed_work.
* A new impl_has_delayed_work! macro that provides adjusted versions of
the container_of logic, that is suitable with delayed work items.
* A `enqueue_delayed` method that can enqueue a delayed work item.
This patch does *not* rely on the fact that `struct delayed_work`
contains `struct work_struct` at offset zero. It will continue to work
even if the layout is changed to hold the `work` field at a different
offset.
Please see the example introduced at the top of the file for example
usage of delayed work items.
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20250711-workqueue-delay-v3-1-3fe17b18b9d1@google.com
[ Replaced `as _` with `as ffi::c_int` to clean warning. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
In the previous patch we added Opaque::cast_from() that performs the
opposite operation to Opaque::raw_get(). For consistency with this
naming, rename raw_get() to cast_from().
There are a few other options such as calling cast_from() something
closer to raw_get() rather than renaming this method. However, I could
not find a great naming scheme that works with raw_get(). The previous
version of this patch used from_raw(), but functions of that name
typically have a different signature, so that's not a great option.
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Benno Lossin <lossin@kernel.org>
Acked-by: Andreas Hindborg <a.hindborg@kernel.org>
Acked-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/r/20250624-opaque-from-raw-v2-2-e4da40bdc59c@google.com
[ Removed `HrTimer::raw_get` change. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Since commit b20fbbc08a ("rust: check type of `$ptr` in
`container_of!`") we have enforced that the field pointer passed to
container_of! must match the declared field. This caused mismatches when
using a pointer to bindings::x for fields of type Opaque<bindings::x>.
This situation encourages the user to simply pass field.cast() to the
container_of! macro, but this is not great because you might
accidentally pass a *mut bindings::y when the field type is
Opaque<bindings::x>, which would be wrong.
To help catch this kind of mistake, add a new Opaque::cast_from that
wraps a raw pointer in Opaque without changing the inner type. Also
update the docs to reflect this as well as some existing users.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Andreas Hindborg <a.hindborg@kernel.org>
Acked-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/r/20250624-opaque-from-raw-v2-1-e4da40bdc59c@google.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
The intended implementations of `ForeignOwnable` will not return null
pointers from `into_foreign`, as this would render the implementation of
`try_from_foreign` useless. Current users of `ForeignOwnable` rely on
`into_foreign` returning non-null pointers. So require `into_foreign` to
return non-null pointers.
Suggested-by: Benno Lossin <lossin@kernel.org>
Suggested-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20250612-pointed-to-v3-2-b009006d86a1@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
The current implementation of `ForeignOwnable` is leaking the type of the
opaque pointer to consumers of the API. This allows consumers of the opaque
pointer to rely on the information that can be extracted from the pointer
type.
To prevent this, change the API to the version suggested by Maira
Canal (link below): Remove `ForeignOwnable::PointedTo` in favor of a
constant, which specifies the alignment of the pointers returned by
`into_foreign`.
With this change, `ArcInner` no longer needs `pub` visibility, so change it
to private.
Suggested-by: Alice Ryhl <aliceryhl@google.com>
Suggested-by: Maíra Canal <mcanal@igalia.com>
Link: https://lore.kernel.org/r/20240309235927.168915-3-mcanal@igalia.com
Acked-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20250612-pointed-to-v3-1-b009006d86a1@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
The previous version used a verbose `match` to get
`current`, which may be slightly confusing at first
glance.
This change makes it shorter and more clearly expresses
the intent: prefer `next` if available, otherwise fall
back to `prev`.
Signed-off-by: Onur Özkan <work@onurozkan.dev>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://lore.kernel.org/r/20250708075850.25789-1-work@onurozkan.dev
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Currently, Rust code uses a typedef for unsigned long to represent
userspace addresses. This is unfortunate because it means that userspace
addresses could accidentally be mixed up with other integers. To
alleviate that, we introduce a new UserPtr struct that wraps a raw
pointer to represent a userspace address. By using a struct, type
checking enforces that userspace addresses cannot be mixed up with
anything else.
This is similar to the __user annotation in C that detects cases where
user pointers are mixed with non-user pointers.
Note that unlike __user pointers in C, this type is just a pointer
without a target type. This means that it can't detect cases such as
mixing up which struct this user pointer references. However, that is
okay due to the way this is intended to be used - generally, you create
a UserPtr in your ioctl callback from the provided usize *before*
dispatching on which ioctl is in use, and then after dispatching on the
ioctl you pass the UserPtr into a UserSliceReader or UserSliceWriter;
selecting the target type does not happen until you have obtained the
UserSliceReader/Writer.
The UserPtr type is not marked with #[derive(Debug)], which means that
it's not possible to print values of this type. This avoids ASLR
leakage.
The type is added to the prelude as it is a fairly fundamental type
similar to c_int. The wrapping_add() method is renamed to
wrapping_byte_add() for consistency with the method name found on raw
pointers.
Reviewed-by: Benno Lossin <lossin@kernel.org>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Christian Schrefl <chrisi.schrefl@gmail.com>
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20250616-userptr-newtype-v3-1-5ff7b2d18d9e@google.com
[ Reworded title. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
This patch adds a more convenient method for reading C strings from
userspace. Logic is added to NUL-terminate the buffer when necessary so
that a &CStr can be returned.
Note that we treat attempts to read past `self.length` as a fault, so
this returns EFAULT if that limit is exceeded before `buf.len()` is
reached.
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Link: https://lore.kernel.org/r/20250616-strncpy-from-user-v5-2-2d3fb0e1f5af@google.com
[ Use `from_mut` to clean `clippy::ref_as_ptr` lint. Reworded
title. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
This patch adds a direct wrapper around the C function of the same name.
It's not really intended for direct use by Rust code since
strncpy_from_user has a somewhat unfortunate API where it only
nul-terminates the buffer if there's space for the nul-terminator. This
means that a direct Rust wrapper around it could not return a &CStr
since the buffer may not be a cstring. However, we still add the method
to build more convenient APIs on top of it, which will happen in
subsequent patches.
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20250616-strncpy-from-user-v5-1-2d3fb0e1f5af@google.com
[ Reworded title. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Added:
- 'impl<T, E> [Pin]Init<T, E> for Result<T, E>', so results are now
(pin-)initializers.
- 'Zeroable::init_zeroed()' delegating to 'init_zeroed()'.
- New 'zeroed()', a safe version of 'mem::zeroed()' and also provide
it via 'Zeroable::zeroed()'.
- Implement 'Zeroable' for 'Option<&T>' and 'Option<&mut T>'.
- Implement 'Zeroable' for 'Option<[unsafe] [extern "abi"]
fn(...args...) -> ret>' for '"Rust"' and '"C"' ABIs and up to 20
arguments.
Changed:
- Blanket impls of 'Init' and 'PinInit' from 'impl<T, E> [Pin]Init<T, E>
for T' to 'impl<T> [Pin]Init<T> for T'.
- Renamed 'zeroed()' to 'init_zeroed()'.
Upstream dev news:
- More CI improvements to deny warnings, use '--all-targets'. Also check
the synchronization status of the two '-next' branches in upstream and
the kernel.
-----BEGIN PGP SIGNATURE-----
iIgEABYKADAWIQQjEG/HT3UeYLJybLTomd21rZaLygUCaGqd4RIcbG9zc2luQGtl
cm5lbC5vcmcACgkQ6Jndta2Wi8qKagD/aBH4iwbal0DHbYx36TMfkvunp6pkKAo1
uu7qbmNwMMwBAKuRb41xA2AvllcYy/aMsb5H00o3iVLOzpMUHNnOFdIJ
=0DbP
-----END PGP SIGNATURE-----
Merge tag 'pin-init-v6.17' of https://github.com/Rust-for-Linux/linux into rust-next
Pull pin-init updates from Benno Lossin:
"Added:
- 'impl<T, E> [Pin]Init<T, E> for Result<T, E>', so results are now
(pin-)initializers.
- 'Zeroable::init_zeroed()' delegating to 'init_zeroed()'.
- New 'zeroed()', a safe version of 'mem::zeroed()' and also provide
it via 'Zeroable::zeroed()'.
- Implement 'Zeroable' for 'Option<&T>' and 'Option<&mut T>'.
- Implement 'Zeroable' for 'Option<[unsafe] [extern "abi"]
fn(...args...) -> ret>' for '"Rust"' and '"C"' ABIs and up to 20
arguments.
Changed:
- Blanket impls of 'Init' and 'PinInit' from 'impl<T, E>
[Pin]Init<T, E> for T' to 'impl<T> [Pin]Init<T> for T'.
- Renamed 'zeroed()' to 'init_zeroed()'.
Upstream dev news:
- More CI improvements to deny warnings, use '--all-targets'. Also
check the synchronization status of the two '-next' branches in
upstream and the kernel."
Acked-by: Andreas Hindborg <a.hindborg@kernel.org>
* tag 'pin-init-v6.17' of https://github.com/Rust-for-Linux/linux:
rust: pin-init: examples, tests: use `ignore` instead of conditionally compiling tests
rust: init: remove doctest's `Error::from_errno` workaround
rust: init: re-enable doctests
rust: pin-init: implement `ZeroableOption` for function pointers with up to 20 arguments
rust: pin-init: change `impl Zeroable for Option<NonNull<T>>` to `ZeroableOption for NonNull<T>`
rust: pin-init: implement `ZeroableOption` for `&T` and `&mut T`
rust: pin-init: add `zeroed()` & `Zeroable::zeroed()` functions
rust: pin-init: add `Zeroable::init_zeroed`
rust: pin-init: rename `zeroed` to `init_zeroed`
rust: pin-init: feature-gate the `stack_init_reuse` test on the `std` feature
rust: pin-init: examples: pthread_mutex: disable the main test for miri
rust: pin-init: examples, tests: add conditional compilation in order to compile under any feature combination
rust: pin-init: change blanket impls for `[Pin]Init` and add one for `Result<T, E>`
rust: pin-init: improve safety documentation for `impl<T> [Pin]Init<T> for T`
Implement `Borrow<T>` and `BorrowMut<T>` for `UniqueArc<T>`, and
`Borrow<T>` for `Arc<T>`. This allows these containers to be used in
generic APIs asking for types implementing those traits. `T` and `&mut
T` also implement those traits allowing users to use either owned,
shared or borrowed values.
`ForeignOwnable` makes a call to its own `borrow` method which must be
disambiguated.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://lore.kernel.org/r/20250616-borrow_impls-v4-2-36f9beb3fe6a@nvidia.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Given the safety requirements of as_slice_mut() and write() taking an
immutable reference is technically not incorrect.
However, let's leverage the compiler's capabilities and require a
mutable reference to ensure exclusive access.
This also fixes a clippy warning introduced with 1.88:
warning: mutable borrow from immutable input(s)
--> rust/kernel/dma.rs:297:78
|
297 | pub unsafe fn as_slice_mut(&self, offset: usize, count: usize) -> Result<&mut [T]> {
| ^^^^^^^^
Fixes: d37a39f607 ("rust: dma: add as_slice/write functions for CoherentAllocation")
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Abdiel Janulgue <abdiel.janulgue@gmail.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://lore.kernel.org/r/20250628165120.90149-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add a wrapper for fsleep(), flexible sleep functions in
include/linux/delay.h which typically deals with hardware delays.
The kernel supports several sleep functions to handle various lengths
of delay. This adds fsleep(), automatically chooses the best sleep
method based on a duration.
fsleep() can only be used in a nonatomic context. This requirement is
not checked by these abstractions, but it is intended that klint [1]
or a similar tool will be used to check it in the future.
Link: https://rust-for-linux.com/klint [1]
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Fiona Behrens <me@kloenk.dev>
Tested-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://lore.kernel.org/r/20250617144155.3903431-3-fujita.tomonori@gmail.com
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Prevent downstream crates or drivers from implementing `HrTimerMode`
for arbitrary types, which could otherwise leads to unsupported
behavior.
Introduce a `private::Sealed` trait and implement it for all types
that implement `HrTimerMode`.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://lore.kernel.org/r/20250617232806.3950141-1-fujita.tomonori@gmail.com
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
In Rust Binder I need to be able to determine whether a red/black tree
is empty. Thus, add a method for that operation to replace
rbtree.iter().next().is_none()
This is terrible, so add a method for this purpose. We do not add a
RBTree::len method because computing the number of elements requires
iterating the entire tree, but checking whether it is empty can be done
cheaply.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Link: https://lore.kernel.org/r/20250616-rbtree-is-empty-v1-1-61f7cfb012e3@google.com
[ Adjusted title. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Remove the use of `Ktime` from the hrtimer code, which was originally
introduced as a temporary workaround. The hrtimer has now been fully
converted to use the `Instant` and `Delta` types instead.
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://lore.kernel.org/r/20250610132823.3457263-6-fujita.tomonori@gmail.com
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Add a `TimerMode` associated type to the `HasHrTimer` trait to
represent the operational mode of the timer, such as absolute or
relative expiration. This new type must implement the `HrTimerMode`
trait, which defines how expiration values are interpreted.
Update the `start()` method to accept an `expires` parameter of type
`<Self::TimerMode as HrTimerMode>::Expires` instead of the fixed `Ktime`.
This enables different timer modes to provide strongly typed expiration
values, such as `Instant<C>` or `Delta`.
The `impl_has_hr_timer` macro is also extended to allow specifying the
`HrTimerMode`. In the following example, it guarantees that the
`start()` method for `Foo` only accepts `Instant<Monotonic>`. Using a
`Delta` or an `Instant` with a different clock source will result in a
compile-time error:
struct Foo {
#[pin]
timer: HrTimer<Self>,
}
impl_has_hr_timer! {
impl HasHrTimer<Self> for Foo {
mode : AbsoluteMode<Monotonic>,
field : self.timer
}
}
This design eliminates runtime mismatches between expires types and
clock sources, and enables stronger type-level guarantees throughout
hrtimer.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://lore.kernel.org/r/20250610132823.3457263-5-fujita.tomonori@gmail.com
[ changed conversion method names to `as_*` - Andreas ]
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Introduce the `HrTimerExpires` trait to represent types that can be
used as expiration values for high-resolution timers. Define a
required method, `into_nanos()`, which returns the expiration time as a
raw nanosecond value suitable for use with C's hrtimer APIs.
Also extend the `HrTimerMode` to use the `HrTimerExpires` trait.
This refactoring is a preparation for enabling hrtimer code to work
uniformly with both absolute and relative expiration modes.
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://lore.kernel.org/r/20250610132823.3457263-4-fujita.tomonori@gmail.com
[ changed conversion method names to `as_*` - Andreas ]
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Replace the `HrTimerMode` enum with a trait-based approach that uses
zero-sized types to represent each mode of operation. Each mode now
implements the `HrTimerMode` trait.
This refactoring is a preparation for replacing raw `Ktime` in HrTimer
with the `Instant` and `Delta` types, and for making `HrTimer` generic
over a `ClockSource`.
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://lore.kernel.org/r/20250610132823.3457263-3-fujita.tomonori@gmail.com
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Removed reference to internal variables in the comment of `IoMem`
This avoids using private variable names in public documentation.
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://github.com/Rust-for-Linux/linux/issues/1167
Signed-off-by: Sai Vishnu M <saivishnu725@gmail.com>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Link: https://lore.kernel.org/r/20250602164923.48893-2-saivishnu725@gmail.com
[ Reworded title and adjusted tags. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Use a consistent `# Examples` heading in rustdoc across the codebase.
Some modules previously used `## Examples` (even when they should be
available as top-level headers), while others used `# Example`, which
deviates from the preferred `# Examples` style.
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Benno Lossin <lossin@kernel.org>
Link: https://lore.kernel.org/r/ddd5ce0ac20c99a72a4f1e4322d3de3911056922.1749545815.git.viresh.kumar@linaro.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Commit 38559da6af ("rust: module: introduce `authors` key") introduced
a new `authors` key to support multiple module authors, while keeping
the old `author` key for backward compatibility.
Now that most in-tree modules have migrated to `authors`, remove:
1. The deprecated `author` key support from the module macro
2. Legacy `author` entries from remaining modules
Signed-off-by: Guilherme Giacomo Simoes <trintaeoitogc@gmail.com>
Acked-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20250609122200.179307-1-trintaeoitogc@gmail.com
[ Reworded slightly. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Using `unwrap()` in kernel doctests can cause panics on error and may
give newcomers the mistaken impression that panicking is acceptable
in kernel code.
Replace all `.unwrap()` calls in `kernel::list`
examples with `.ok_or(EINVAL)?` so that errors are properly propagated.
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://github.com/Rust-for-Linux/linux/issues/1164
Reviewed-by: Benno Lossin <lossin@kernel.org>
Signed-off-by: Albin Babu Varghese <albinbabuvarghese20@gmail.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/r/20250527204928.5117-1-albinbabuvarghese20@gmail.com
[ Reworded slightly. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Remove `use core::ffi::c_void`, which shadows `kernel::ffi::c_void`
brought in via `use crate::prelude::*`, to maintain consistency and
centralize the abstraction.
Since `kernel::ffi::c_void` is a straightforward re-export of
`core::ffi::c_void`, both are functionally equivalent. However, using
`kernel::ffi::c_void` improves consistency across the kernel's Rust code
and provides a unified reference point in case the definition ever needs
to change, even if such a change is unlikely.
Reviewed-by: Benno Lossin <lossin@kernel.org>
Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089/topic/x/near/520452733
Signed-off-by: Jesung Yang <y.j3ms.n@gmail.com>
Link: https://lore.kernel.org/r/20250528174953.2948570-1-y.j3ms.n@gmail.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
- Clarify wording and be consistent in 'coherent' nomenclature.
- Convert the read!() / write!() macros to return a Result.
- Add as_slice() / write() methods in CoherentAllocation.
- Fix doc-comment of dma_handle().
- Expose count() and size() in CoherentAllocation and add the
corresponding type invariants.
- Implement CoherentAllocation::dma_handle_with_offset().
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS2q/xV6QjXAdC7k+1FlHeO1qrKLgUCaFlvFQAKCRBFlHeO1qrK
LpXYAP4xXaXFU8lp7mk77ipsXudywidktEINLwnkkpu9ktFM9gD/aXmgnWN5hFvX
6AYX6v+UTbymqqpIW9uylTteAfQ98ws=
=bO4B
-----END PGP SIGNATURE-----
Merge tag 'topic/dma-features-2025-06-23' into alloc-next
DMA features for v6.17
- Clarify wording and be consistent in 'coherent' nomenclature.
- Convert the read!() / write!() macros to return a Result.
- Add as_slice() / write() methods in CoherentAllocation.
- Fix doc-comment of dma_handle().
- Expose count() and size() in CoherentAllocation and add the
corresponding type invariants.
- Implement CoherentAllocation::dma_handle_with_offset().
Sometimes one may want to obtain a DMA handle starting at a given
offset. This can be done by adding said offset to the result of
`dma_handle()`, but doing so on the client side carries the risk that
the operation will go outside the bounds of the allocation.
Thus, add a `dma_handle_with_offset` method that adds the desired offset
after checking that it is still valid.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://lore.kernel.org/r/20250619-nova-frts-v6-3-ecf41ef99252@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
These properties are very useful to have (and to be used by nova-core)
and should be accessible, hence add them.
Additionally, add type invariants for the size of an allocation.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://lore.kernel.org/r/20250619-nova-frts-v6-2-ecf41ef99252@nvidia.com
[ Slightly extend the commit message. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
