summaryrefslogtreecommitdiff
path: root/rust
AgeCommit message (Collapse)Author
2024-08-31rust: rbtree: add cursorMatt Gilbride
Add a cursor interface to `RBTree`, supporting the following use cases: - Inspect the current node pointed to by the cursor, inspect/move to it's neighbors in sort order (bidirectionally). - Mutate the tree itself by removing the current node pointed to by the cursor, or one of its neighbors. Add functions to obtain a cursor to the tree by key: - The node with the smallest key - The node with the largest key - The node matching the given key, or the one with the next larger key The cursor abstraction is needed by the binder driver to efficiently search for nodes and (conditionally) modify them, as well as their neighbors [1]. Link: https://lore.kernel.org/rust-for-linux/20231101-rust-binder-v1-6-08ba9197f637@google.com/ [1] Co-developed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Matt Gilbride <mattgilbride@google.com> Link: https://lore.kernel.org/r/20240822-b4-rbtree-v12-4-014561758a57@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-31rust: rbtree: add mutable iteratorWedson Almeida Filho
Add mutable Iterator implementation for `RBTree`, allowing iteration over (key, value) pairs in key order. Only values are mutable, as mutating keys implies modifying a node's position in the tree. Mutable iteration is used by the binder driver during shutdown to clean up the tree maintained by the "range allocator" [1]. Link: https://lore.kernel.org/rust-for-linux/20231101-rust-binder-v1-6-08ba9197f637@google.com/ [1] Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Matt Gilbride <mattgilbride@google.com> Link: https://lore.kernel.org/r/20240822-b4-rbtree-v12-3-014561758a57@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-31rust: rbtree: add iteratorWedson Almeida Filho
- Add Iterator implementation for `RBTree`, allowing iteration over (key, value) pairs in key order. - Add individual `keys()` and `values()` functions to iterate over keys or values alone. - Update doctests to use iteration instead of explicitly getting items. Iteration is needed by the binder driver to enumerate all values in a tree for oneway spam detection [1]. Link: https://lore.kernel.org/rust-for-linux/20231101-rust-binder-v1-17-08ba9197f637@google.com/ [1] Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Matt Gilbride <mattgilbride@google.com> Link: https://lore.kernel.org/r/20240822-b4-rbtree-v12-2-014561758a57@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-31rust: rbtree: add red-black tree implementation backed by the C versionWedson Almeida Filho
The rust rbtree exposes a map-like interface over keys and values, backed by the kernel red-black tree implementation. Values can be inserted, deleted, and retrieved from a `RBTree` by key. This base abstraction is used by binder to store key/value pairs and perform lookups, for example the patch "[PATCH RFC 03/20] rust_binder: add threading support" in the binder RFC [1]. Link: https://lore.kernel.org/rust-for-linux/20231101-rust-binder-v1-3-08ba9197f637@google.com/ [1] Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Matt Gilbride <mattgilbride@google.com> Link: https://lore.kernel.org/r/20240822-b4-rbtree-v12-1-014561758a57@google.com [ Updated link to docs.kernel.org. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-30rust: net::phy unified genphy_read_status function for C22 and C45 registersFUJITA Tomonori
Add unified genphy_read_status function for C22 and C45 registers. Instead of having genphy_c22 and genphy_c45 methods, this unifies genphy_read_status functions for C22 and C45. Reviewed-by: Trevor Gross <tmgross@umich.edu> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-08-30rust: net::phy unified read/write API for C22 and C45 registersFUJITA Tomonori
Add the unified read/write API for C22 and C45 registers. The abstractions support access to only C22 registers now. Instead of adding read/write_c45 methods specifically for C45, a new reg module supports the unified API to access C22 and C45 registers with trait, by calling an appropriate phylib functions. Reviewed-by: Trevor Gross <tmgross@umich.edu> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-08-30rust: net::phy implement AsRef<kernel::device::Device> traitFUJITA Tomonori
Implement AsRef<kernel::device::Device> trait for Device. A PHY driver needs a reference to device::Device to call the firmware API. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Trevor Gross <tmgross@umich.edu> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-08-30rust: net::phy support probe callbackFUJITA Tomonori
Support phy_driver probe callback, used to set up device-specific structures. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Trevor Gross <tmgross@umich.edu> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-08-30rust: sizes: add commonly used constantsFUJITA Tomonori
Add rust equivalent to include/linux/sizes.h, makes code more readable. Only SZ_*K that QT2025 PHY driver uses are added. Make generated constants accessible with a proper type. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Trevor Gross <tmgross@umich.edu> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-08-27rust: alloc: eschew `Box<MaybeUninit<T>>::write`Jubilee Young
Upstream Rust's libs-api team has consensus for stabilizing some of `feature(new_uninit)`, but not for `Box<MaybeUninit<T>>::write`. Instead, we can use `MaybeUninit<T>::write`, so Rust for Linux can drop the feature after stabilization. That will happen after merging, as the FCP has completed [1]. This is required before stabilization because remaining-unstable API will be divided into new features. This code doesn't know about those yet. It can't: they haven't landed, as the relevant PR is blocked on rustc's CI testing Rust-for-Linux without this patch. [ The PR has landed [2] and will be released in Rust 1.82.0 (expected on 2024-10-17), so we could conditionally enable the new unstable feature (`box_uninit_write` [3]) instead, but just for a single `unsafe` block it is probably not worth it. For the time being, I added it to the "nice to have" section of our unstable features list. - Miguel ] Link: https://github.com/rust-lang/rust/issues/63291#issuecomment-2183022955 [1] Link: https://github.com/rust-lang/rust/pull/129416 [2] Link: https://github.com/rust-lang/rust/issues/129397 [3] Signed-off-by: Jubilee Young <workingjubilee@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> [ Reworded slightly. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-25rust: enable rustdoc's `--generate-link-to-definition`Miguel Ojeda
In Rust 1.56.0 [1], rustdoc introduced the "jump to definition" feature [2], i.e. the unstable flag `--generate-link-to-definition`. It adds links to the source view of the documentation. For instance, in the source view of `rust/kernel/sync.rs`, for this code: impl Default for LockClassKey { fn default() -> Self { Self::new() } } It will add three hyperlinks: - `Default` points to the rendered "Trait `core::default::Default`" page (not the source view, since it goes to another crate, though this may change). - `LockClassKey` points to the `pub struct LockClassKey(...);` line in the same page, highlighting the line number. - `Self::new()` points to the `pub const fn new() -> Self { ... }` associated function, highlighting its line numbers (i.e. for the full function). This makes the source view more useful and a bit closer to the experience in e.g. the Elixir Cross Referencer [3]. I have provisionally enabled it for rust.docs.kernel.org [4] -- one can take a look at the source view there for an example of how it looks like. Thus enable it. Cc: Guillaume Gomez <guillaume1.gomez@gmail.com> Link: https://github.com/rust-lang/rust/pull/84176 [1] Link: https://github.com/rust-lang/rust/issues/89095 [2] Link: https://elixir.bootlin.com [3] Link: https://rust.docs.kernel.org [4] Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240818141249.387166-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-25rust: types: add `ARef::into_raw`Kartik Prajapati
Add a method for `ARef` that is analogous to `Arc::into_raw`. It is the inverse operation of `ARef::from_raw`, and allows you to convert the `ARef` back into a raw pointer while retaining ownership of the refcount. This new function will be used by [1] for converting the type in an `ARef` using `ARef::from_raw(ARef::into_raw(me).cast())`. Alice has also needed the same function for other use-cases in the past, but [1] is the first to go upstream. This was implemented independently by Kartik and Alice. The two versions were merged by Alice, so all mistakes are Alice's. Link: https://lore.kernel.org/r/20240801-vma-v3-1-db6c1c0afda9@google.com [1] Link: https://github.com/Rust-for-Linux/linux/issues/1044 Signed-off-by: Kartik Prajapati <kartikprajapati987@gmail.com> Co-developed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> [ Reworded to correct the author reference and changed tag to Link since it is not a bug. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-25rust: kernel: use docs.kernel.org links in code documentationMichael Vetter
Use links to docs.kernel.org instead of www.kernel.org/doc/html/latest in the code documentation. The links are shorter and cleaner. Link: https://github.com/Rust-for-Linux/linux/issues/1101 Signed-off-by: Michael Vetter <jubalh@iodoru.org> [ Reworded slightly. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-23rust: list: add ListArcFieldAlice Ryhl
One way to explain what `ListArc` does is that it controls exclusive access to the prev/next pointer field in a refcounted object. The feature of having a special reference to a refcounted object with exclusive access to specific fields is useful for other things, so provide a general utility for that. This is used by Rust Binder to keep track of which processes have a reference to a given node. This involves an object for each process/node pair, that is referenced by both the process and the node. For some fields in this object, only the process's reference needs to access them (and it needs mutable access), so Binder uses a ListArc to give the process's reference exclusive access. Reviewed-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240814-linked-list-v5-10-f5f5e8075da0@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-23rust: list: support heterogeneous listsAlice Ryhl
Support linked lists that can hold many different structs at once. This is generally done using trait objects. The main challenge is figuring what the struct is given only a pointer to the ListLinks. We do this by storing a pointer to the struct next to the ListLinks field. The container_of operation will then just read that pointer. When the type is a trait object, that pointer will be a fat pointer whose metadata is a vtable that tells you what kind of struct it is. Heterogeneous lists are heavily used by Rust Binder. There are a lot of so-called todo lists containing various events that need to be delivered to userspace next time userspace calls into the driver. And there are quite a few different todo item types: incoming transaction, changes to refcounts, death notifications, and more. Reviewed-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240814-linked-list-v5-9-f5f5e8075da0@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-23rust: list: add cursorAlice Ryhl
The cursor is very similar to the list iterator, but it has one important feature that the iterator doesn't: it can be used to remove items from the linked list. This feature cannot be added to the iterator because the references you get from the iterator are considered borrows of the original list, rather than borrows of the iterator. This means that there's no way to prevent code like this: let item = iter.next(); iter.remove(); use(item); If `iter` was a cursor instead of an iterator, then `item` will be considered a borrow of `iter`. Since `remove` destroys `iter`, this means that the borrow-checker will prevent uses of `item` after the call to `remove`. So there is a trade-off between supporting use in traditional for loops, and supporting removal of elements as you iterate. Iterators and cursors represents two different choices on that spectrum. Rust Binder needs cursors for the list of death notifications that a process is currently handling. When userspace tells Binder that it has finished processing the death notification, Binder will iterate the list to search for the relevant item and remove it. Reviewed-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240814-linked-list-v5-8-f5f5e8075da0@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-23rust: list: add iteratorsAlice Ryhl
Rust Binder has lists containing stuff such as all contexts or all processes, and sometimes needs to iterate over them. This patch enables Rust Binder to do that using a normal for loop. The iterator returns the ArcBorrow type, so it is possible to grab a refcount to values while iterating. Reviewed-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240814-linked-list-v5-7-f5f5e8075da0@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-23rust: list: add ListAlice Ryhl
Add the actual linked list itself. The linked list uses the following design: The List type itself just has a single pointer to the first element of the list. And the actual list items then form a cycle. So the last item is `first->prev`. This is slightly different from the usual kernel linked list. Matching that exactly would amount to giving List two pointers, and having it be part of the cycle of items. This alternate design has the advantage that the cycle is never completely empty, which can reduce the number of branches in some cases. However, it also has the disadvantage that List must be pinned, which this design is trying to avoid. Having the list items form a cycle rather than having null pointers at the beginning/end is convenient for several reasons. For one, it lets us store only one pointer in List, and it simplifies the implementation of several functions. Unfortunately, the `remove` function that removes an arbitrary element from the list has to be unsafe. This is needed because there is no way to handle the case where you pass an element from the wrong list. For example, if it is the first element of some other list, then that other list's `first` pointer would not be updated. Similarly, it could be a data race if you try to remove it from two different lists in parallel. (There's no problem with passing `remove` an item that's not in any list. Additionally, other removal methods such as `pop_front` need not be unsafe, as they can't be used to remove items from another list.) A future patch in this series will introduce support for cursors that can be used to remove arbitrary items without unsafe code. Reviewed-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240814-linked-list-v5-6-f5f5e8075da0@google.com [ Fixed a few typos. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-23rust: list: add macro for implementing ListItemAlice Ryhl
Adds a macro for safely implementing the ListItem trait. As part of the implementation of the macro, we also provide a HasListLinks trait similar to the workqueue's HasWorkItem trait. The HasListLinks trait is only necessary if you are implementing ListItem using the impl_list_item macro. Reviewed-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240814-linked-list-v5-5-f5f5e8075da0@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-23rust: list: add struct with prev/next pointersAlice Ryhl
Define the ListLinks struct, which wraps the prev/next pointers that will be used to insert values into a List in a future patch. Also define the ListItem trait, which is implemented by structs that have a ListLinks field. The ListItem trait provides four different methods that are all essentially container_of or the reverse of container_of. Two of them are used before inserting/after removing an item from the list, and the two others are used when looking at a value without changing whether it is in a list. This distinction is introduced because it is needed for the patch that adds support for heterogeneous lists, which are implemented by adding a third pointer field with a fat pointer to the full struct. When inserting into the heterogeneous list, the pointer-to-self is updated to have the right vtable, and the container_of operation is implemented by just returning that pointer instead of using the real container_of operation. Reviewed-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240814-linked-list-v5-4-f5f5e8075da0@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-23rust: list: add tracking for ListArcAlice Ryhl
Add the ability to track whether a ListArc exists for a given value, allowing for the creation of ListArcs without going through UniqueArc. The `impl_list_arc_safe!` macro is extended with a `tracked_by` strategy that defers the tracking of ListArcs to a field of the struct. Additionally, the AtomicListArcTracker type is introduced, which can track whether a ListArc exists using an atomic. By deferring the tracking to a field of type AtomicListArcTracker, structs gain the ability to create ListArcs without going through a UniqueArc. Rust Binder uses this for some objects where we want to be able to insert them into a linked list at any time. Using the AtomicListArcTracker, we are able to check whether an item is already in the list, and if not, we can create a `ListArc` and push it. The macro has the ability to defer the tracking of ListArcs to a field, using whatever strategy that field has. Since we don't add any strategies other than AtomicListArcTracker, another similar option would be to hard-code that the field should be an AtomicListArcTracker. However, Rust Binder has a case where the AtomicListArcTracker is not stored directly in the struct, but in a sub-struct. Furthermore, the outer struct is generic: struct Wrapper<T: ?Sized> { links: ListLinks, inner: T, } Here, the Wrapper struct implements ListArcSafe with `tracked_by inner`, and then the various types used with `inner` also uses the macro to implement ListArcSafe. Some of them use the untracked strategy, and some of them use tracked_by with an AtomicListArcTracker. This way, Wrapper just inherits whichever choice `inner` has made. Reviewed-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240814-linked-list-v5-3-f5f5e8075da0@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-23rust: list: add ListArcAlice Ryhl
The `ListArc` type can be thought of as a special reference to a refcounted object that owns the permission to manipulate the `next`/`prev` pointers stored in the refcounted object. By ensuring that each object has only one `ListArc` reference, the owner of that reference is assured exclusive access to the `next`/`prev` pointers. When a `ListArc` is inserted into a `List`, the `List` takes ownership of the `ListArc` reference. There are various strategies for ensuring that a value has only one `ListArc` reference. The simplest is to convert a `UniqueArc` into a `ListArc`. However, the refcounted object could also keep track of whether a `ListArc` exists using a boolean, which could allow for the creation of new `ListArc` references from an `Arc` reference. Whatever strategy is used, the relevant tracking is referred to as "the tracking inside `T`", and the `ListArcSafe` trait (and its subtraits) are used to update the tracking when a `ListArc` is created or destroyed. Note that we allow the case where the tracking inside `T` thinks that a `ListArc` exists, but actually, there isn't a `ListArc`. However, we do not allow the opposite situation where a `ListArc` exists, but the tracking thinks it doesn't. This is because the former can at most result in us failing to create a `ListArc` when the operation could succeed, whereas the latter can result in the creation of two `ListArc` references. Only the latter situation can lead to memory safety issues. This patch introduces the `impl_list_arc_safe!` macro that allows you to implement `ListArcSafe` for types using the strategy where a `ListArc` can only be created from a `UniqueArc`. Other strategies are introduced in later patches. This is part of the linked list that Rust Binder will use for many different things. The strategy where a `ListArc` can only be created from a `UniqueArc` is actually sufficient for most of the objects that Rust Binder needs to insert into linked lists. Usually, these are todo items that are created and then immediately inserted into a queue. The const generic ID allows objects to have several prev/next pointer pairs so that the same object can be inserted into several different lists. You are able to have several `ListArc` references as long as they correspond to different pointer pairs. The ID itself is purely a compile-time concept and will not be present in the final binary. Both the `List` and the `ListArc` will need to agree on the ID for them to work together. Rust Binder uses this in a few places (e.g. death recipients) where the same object can be inserted into both generic todo lists and some other lists for tracking the status of the object. The ID is a const generic rather than a type parameter because the `pair_from_unique` method needs to be able to assert that the two ids are different. There's no easy way to assert that when using types instead of integers. Reviewed-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240814-linked-list-v5-2-f5f5e8075da0@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-23rust: init: add `assert_pinned` macroBenno Lossin
Add a macro to statically check if a field of a struct is marked with `#[pin]` ie that it is structurally pinned. This can be used when `unsafe` code needs to rely on fields being structurally pinned. The macro has a special "inline" mode for the case where the type depends on generic parameters from the surrounding scope. Signed-off-by: Benno Lossin <benno.lossin@proton.me> Co-developed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240814-linked-list-v5-1-f5f5e8075da0@google.com [ Replaced `compile_fail` with `ignore` and a TODO note. Removed `pub` from example to clean `unreachable_pub` lint. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-22rust: init: add `write_[pin_]init` functionsBenno Lossin
Sometimes it is necessary to split allocation and initialization into two steps. One such situation is when reusing existing allocations obtained via `Box::drop_contents`. See [1] for an example. In order to support this use case add `write_[pin_]init` functions to the pin-init API. These functions operate on already allocated smart pointers that wrap `MaybeUninit<T>`. Link: https://lore.kernel.org/rust-for-linux/f026532f-8594-4f18-9aa5-57ad3f5bc592@proton.me/ [1] Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240819112415.99810-2-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-22rust: kernel: add `drop_contents` to `BoxExt`Benno Lossin
Sometimes (see [1]) it is necessary to drop the value inside of a `Box<T>`, but retain the allocation. For example to reuse the allocation in the future. Introduce a new function `drop_contents` that turns a `Box<T>` into `Box<MaybeUninit<T>>` by dropping the value. Link: https://lore.kernel.org/rust-for-linux/20240418-b4-rbtree-v3-5-323e134390ce@google.com/ [1] Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240819112415.99810-1-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-21rust: kernel: fix typos in code commentsMichael Vetter
Fix spelling mistakes in code comments. Signed-off-by: Michael Vetter <jubalh@iodoru.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20240819205731.2163-1-jubalh@iodoru.org [ Reworded slightly. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-21rust: block: fix wrong usage of lockdep APIAndreas Hindborg
When allocating `struct gendisk`, `GenDiskBuilder` is using a dynamic lock class key without registering the key. This is an incorrect use of the API, which causes a `WARN` trace. Fix the issue by using a static lock class key, which is more appropriate for the situation anyway. Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module") Reported-by: Behme Dirk (XC-CP/ESB5) <Dirk.Behme@de.bosch.com> Closes: https://rust-for-linux.zulipchat.com/#narrow/stream/x/topic/x/near/457090036 Signed-off-by: Andreas Hindborg <a.hindborg@samsung.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Link: https://lore.kernel.org/r/20240815074519.2684107-3-nmi@metaspace.dk [ Applied `rustfmt`, reworded slightly and made Zulip link a permalink. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-21rust: kbuild: fix export of bss symbolsAndreas Hindborg
Symbols in the bss segment are not currently exported. This is a problem for Rust modules that link against statics, that are resident in the kernel image. Thus export symbols in the bss segment. Fixes: 2f7ab1267dc9 ("Kbuild: add Rust support") Signed-off-by: Andreas Hindborg <a.hindborg@samsung.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240815074519.2684107-2-nmi@metaspace.dk [ Reworded slightly. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-21rust: enable bindgen's `--enable-function-attribute-detection` flagMiguel Ojeda
`bindgen` is able to detect certain function attributes and annotate functions correspondingly in its output for the Rust side, when the `--enable-function-attribute-detection` is passed. In particular, it is currently able to use `__must_check` in C (`#[must_use]` in Rust), which give us a bunch of annotations that are nice to have to prevent possible issues in Rust abstractions, e.g.: extern "C" { + #[must_use] pub fn kobject_add( kobj: *mut kobject, parent: *mut kobject, fmt: *const core::ffi::c_char, ... ) -> core::ffi::c_int; } Apparently, there are edge cases where this can make generation very slow, which is why it is behind a flag [1], but it does not seem to affect us in any major way at the moment. Thus enable it. Link: https://github.com/rust-lang/rust-bindgen/issues/1465 [1] Link: https://lore.kernel.org/rust-for-linux/CANiq72=u5Nrz_NW3U3_VqywJkD8pECA07q2pFDd1wjtXOWdkAQ@mail.gmail.com/ Reviewed-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20240814163722.1550064-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-21rust: sort blk includes in bindings_helper.hAlice Ryhl
The headers in this file are sorted alphabetically, which makes it easy to quickly resolve conflicts by selecting all of the headers and invoking :'<,'>sort to sort them. To keep this technique to resolve conflicts working, also apply sorting to symbols that are not letters. This file is very prone to merge conflicts, so I think keeping conflict resolution really easy is more important than not messing with git blame history. These includes were originally introduced in commit 3253aba3408a ("rust: block: introduce `kernel::block::mq` module"). Signed-off-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20240809132835.274603-1-aliceryhl@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-19rust: kbuild: auto generate helper exportsGary Guo
This removes the need to explicitly export all symbols. Generate helper exports similarly to what's currently done for Rust crates. These helpers are exclusively called from within Rust code and therefore can be treated similar as other Rust symbols. Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Tested-by: Boqun Feng <boqun.feng@gmail.com> Link: https://lore.kernel.org/r/20240817165302.3852499-1-gary@garyguo.net [ Fixed dependency path, reworded slightly, edited comment a bit and rebased on top of the changes made when applying Andreas' patch (e.g. no `README.md` anymore, so moved the edits). - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-18objtool/kbuild/rust: enable objtool for RustMiguel Ojeda
Now that we should be `objtool`-warning free, enable `objtool` for Rust too. Before this patch series, we were already getting warnings under e.g. IBT builds, since those would see Rust code via `vmlinux.o`. Tested-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240725183325.122827-7-ojeda@kernel.org [ Solved trivial conflict. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-18rust: module: add static pointer to `{init,cleanup}_module()`Miguel Ojeda
Add the equivalent of the `___ADDRESSABLE()` annotation in the `module_{init,exit}` macros to the Rust `module!` macro. Without this, `objtool` would complain if enabled for Rust (under IBT builds), e.g.: samples/rust/rust_print.o: warning: objtool: cleanup_module(): not an indirect call target samples/rust/rust_print.o: warning: objtool: init_module(): not an indirect call target Tested-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240725183325.122827-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-18rust: kbuild: split up helpers.cAndreas Hindborg
This patch splits up the rust helpers C file. When rebasing patch sets on upstream linux, merge conflicts in helpers.c is common and time consuming [1]. Thus, split the file so that each kernel component can live in a separate file. This patch lists helper files explicitly and thus conflicts in the file list is still likely. However, they should be more simple to resolve than the conflicts usually seen in helpers.c. [ Removed `README.md` and undeleted the original comment since now, in v3 of the series, we have a `helpers.c` again; which also allows us to keep the "Sorted alphabetically" line and makes the diff easier. In addition, updated the Documentation/ mentions of the file, reworded title and removed blank lines at the end of `page.c`. - Miguel ] Link: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/Splitting.20up.20helpers.2Ec/near/426694012 [1] Signed-off-by: Andreas Hindborg <a.hindborg@samsung.com> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Dirk Behme <dirk.behme@de.bosch.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20240815103016.2771842-1-nmi@metaspace.dk Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-18rust: error: allow `useless_conversion` for 32-bit buildsMiguel Ojeda
For the new Rust support for 32-bit arm [1], Clippy warns: error: useless conversion to the same type: `i32` --> rust/kernel/error.rs:139:36 | 139 | unsafe { bindings::ERR_PTR(self.0.into()) as *mut _ } | ^^^^^^^^^^^^^ help: consider removing `.into()`: `self.0` | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#useless_conversion = note: `-D clippy::useless-conversion` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::useless_conversion)]` The `self.0.into()` converts an `c_int` into `ERR_PTR`'s parameter which is a `c_long`. Thus, both types are `i32` in 32-bit. Therefore, allow it for those architectures. Link: https://lore.kernel.org/rust-for-linux/2dbd1491-149d-443c-9802-75786a6a3b73@gmail.com/ [1] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Christian Schrefl <chrisi.schrefl@gmail.com> Link: https://lore.kernel.org/r/20240730155702.1110144-1-ojeda@kernel.org [ Fixed typo in tag. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-18rust: types: improve `ForeignOwnable` documentationBenno Lossin
There are no guarantees for the pointer returned by `into_foreign`. This is simply because there is no safety documentation stating any guarantees. Therefore dereferencing and all other operations for that pointer are not allowed in a general context (i.e. when the concrete type implementing the trait is not known). This might be confusing, therefore add normal documentation to state that there are no guarantees given for the pointer. Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240730182251.1466684-1-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-18rust: implement ForeignOwnable for Pin<Box<T>>Alice Ryhl
We already implement ForeignOwnable for Box<T>, but it may be useful to store pinned data in a ForeignOwnable container. This patch makes that possible. This will be used together with upcoming miscdev abstractions, which Binder will use when binderfs is disabled. Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20240730-foreign-ownable-pin-box-v1-1-b1d70cdae541@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-18rust: Implement the smart pointer `InPlaceInit` for `Arc`Alex Mantel
For pinned and unpinned initialization of structs, a trait named `InPlaceInit` exists for uniform access. `Arc` did not implement `InPlaceInit` yet, although the functions already existed. The main reason for that, was that the trait itself returned a `Pin<Self>`. The `Arc` implementation of the kernel is already implicitly pinned. To enable `Arc` to implement `InPlaceInit` and to have uniform access, for in-place and pinned in-place initialization, an associated type is introduced for `InPlaceInit`. The new implementation of `InPlaceInit` for `Arc` sets `Arc` as the associated type. Older implementations use an explicit `Pin<T>` as the associated type. The implemented methods for `Arc` are mostly moved from a direct implementation on `Arc`. There should be no user impact. The implementation for `ListArc` is omitted, because it is not merged yet. Link: https://github.com/Rust-for-Linux/linux/issues/1079 Signed-off-by: Alex Mantel <alexmantel93@mailbox.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20240727042442.682109-1-alexmantel93@mailbox.org [ Removed "Rusts" (Benno). - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-16Merge tag 'rust-fixes-6.11' of https://github.com/Rust-for-Linux/linuxLinus Torvalds
Pull rust fixes from Miguel Ojeda: - Fix '-Os' Rust 1.80.0+ builds adding more intrinsics (also tweaked in upstream Rust for the upcoming 1.82.0). - Fix support for the latest version of rust-analyzer due to a change on rust-analyzer config file semantics (considered a fix since most developers use the latest version of the tool, which is the only one actually supported by upstream). I am discussing stability of the config file with upstream -- they may be able to start versioning it. - Fix GCC 14 builds due to '-fmin-function-alignment' not skipped for libclang (bindgen). - A couple Kconfig fixes around '{RUSTC,BINDGEN}_VERSION_TEXT' to suppress error messages in a foreign architecture chroot and to use a proper default format. - Clean 'rust-analyzer' target warning due to missing recursive make invocation mark. - Clean Clippy warning due to missing indentation in docs. - Clean LLVM 19 build warning due to removed 3dnow feature upstream. * tag 'rust-fixes-6.11' of https://github.com/Rust-for-Linux/linux: rust: x86: remove `-3dnow{,a}` from target features kbuild: rust-analyzer: mark `rust_is_available.sh` invocation as recursive rust: add intrinsics to fix `-Os` builds kbuild: rust: skip -fmin-function-alignment in bindgen flags rust: Support latest version of `rust-analyzer` rust: macros: indent list item in `module!`'s docs rust: fix the default format for CONFIG_{RUSTC,BINDGEN}_VERSION_TEXT rust: suppress error messages from CONFIG_{RUSTC,BINDGEN}_VERSION_TEXT
2024-08-10rust: add intrinsics to fix `-Os` buildsMiguel Ojeda
Alice reported [1] that an arm64 build failed with: ld.lld: error: undefined symbol: __extendsfdf2 >>> referenced by core.a6f5fc5794e7b7b3-cgu.0 >>> rust/core.o:(<f32>::midpoint) in archive vmlinux.a >>> referenced by core.a6f5fc5794e7b7b3-cgu.0 >>> rust/core.o:(<f32>::midpoint) in archive vmlinux.a ld.lld: error: undefined symbol: __truncdfsf2 >>> referenced by core.a6f5fc5794e7b7b3-cgu.0 >>> rust/core.o:(<f32>::midpoint) in archive vmlinux.a Rust 1.80.0 or later together with `CONFIG_CC_OPTIMIZE_FOR_SIZE=y` is what triggers it. In addition, x86_64 builds also fail the same way. Similarly, compiling with Rust 1.82.0 (currently in nightly) makes another one appear, possibly due to the LLVM 19 upgrade there: ld.lld: error: undefined symbol: __eqdf2 >>> referenced by core.20495ea57a9f069d-cgu.0 >>> rust/core.o:(<f64>::next_up) in archive vmlinux.a >>> referenced by core.20495ea57a9f069d-cgu.0 >>> rust/core.o:(<f64>::next_down) in archive vmlinux.a Gary adds [1]: > Usually the fix on rustc side is to mark those functions as `#[inline]` > > All of {midpoint,next_up,next_down} are indeed unstable functions not > marked as inline... Fix all those by adding those intrinsics to our usual workaround. [ Trevor quickly submitted a fix to upstream Rust [2] that has already been merged, to be released in Rust 1.82.0 (2024-10-17). - Miguel ] Cc: Gary Guo <gary@garyguo.net> Reported-by: Alice Ryhl <aliceryhl@google.com> Closes: https://rust-for-linux.zulipchat.com/#narrow/stream/x/topic/x/near/455637364 [1] Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://github.com/rust-lang/rust/pull/128749 [2] Link: https://lore.kernel.org/r/20240806150619.192882-1-ojeda@kernel.org [ Shortened Zulip link. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-10kbuild: rust: skip -fmin-function-alignment in bindgen flagsZehui Xu
GCC 14 recently added -fmin-function-alignment option and the root Makefile uses it to replace -falign-functions when available. However, this flag can cause issues when passed to the Rust Makefile and affect the bindgen process. Bindgen relies on libclang to parse C code, and currently does not support the -fmin-function-alignment flag, leading to compilation failures when GCC 14 is used. This patch addresses the issue by adding -fmin-function-alignment to the bindgen_skip_c_flags in rust/Makefile. This prevents the flag from causing compilation issues. [ Matthew and Gary confirm function alignment should not change the ABI in a way that bindgen would care about, thus we did not need the extra logic for bindgen from v2. - Miguel ] Link: https://lore.kernel.org/linux-kbuild/20240222133500.16991-1-petr.pavlu@suse.com/ Signed-off-by: Zehui Xu <zehuixu@whu.edu.cn> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240731134346.10630-1-zehuixu@whu.edu.cn [ Reworded title. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-07rust: Support latest version of `rust-analyzer`Sarthak Singh
Sets the `sysroot` field in rust-project.json which is now needed in newer versions of rust-analyzer instead of the `sysroot_src` field. Till [1] `rust-analyzer` used to guess the `sysroot` based on the `sysroot_src` at [2]. Now `sysroot` is a required parameter for a `rust-project.json` file. It is required because `rust-analyzer` need it to find the proc-macro server [3]. In the current version of `rust-analyzer` the `sysroot_src` is only used to include the inbuilt library crates (std, core, alloc, etc) [4]. Since we already specify the core library to be included in the `rust-project.json` we don't need to define the `sysroot_src`. Code editors like VS Code try to use the latest version of rust-analyzer (which is updated every week) instead of the version of rust-analyzer that comes with the rustup toolchain (which is updated every six weeks along with the rust version). Without this change `rust-analyzer` is breaking for anyone using VS Code. As they are getting the latest version of `rust-analyzer` with the changes made in [1]. `rust-analyzer` will also start breaking for other developers as they update their rust version (assuming that also updates the rust-analyzer version on their system). This patch should work with every setup as there is no more guess work being done by `rust-analyzer`. [ Lukas, who leads the rust-analyzer team, says: `sysroot_src` is required now if you want to have the sysroot source libraries be loaded. I think we used to infer it as `{sysroot}/lib/rustlib/src/rust/library` before when only the `sysroot` field was given but that was since changed to make it possible in having a sysroot without the standard library sources (that is only have the binaries available). So if you want the library sources to be loaded by rust-analyzer you will have to set that field as well now. - Miguel ] Link: https://github.com/rust-lang/rust-analyzer/pull/17287 [1] Link: https://github.com/rust-lang/rust-analyzer/blob/f372a8a1176ff8dd5f45ab2ddd45f3530db0374f/crates/project-model/src/workspace.rs#L367-L374 [2] Link: https://github.com/rust-lang/rust-analyzer/blob/eeb192b79aeac47b40add66347022af17a74fbaf/crates/project-model/src/sysroot.rs#L180-L192 [3] Link: https://github.com/search?q=repo%3AVeykril%2Frust-analyzer%20src_root()&type=code [4] Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Signed-off-by: Sarthak Singh <sarthak.singh99@gmail.com> Link: https://rust-for-linux.zulipchat.com/#narrow/stream/291565-Help/topic/How.20to.20rust-analyzer.20correctly.20working Link: https://lore.kernel.org/r/20240724172713.899399-1-sarthak.singh99@gmail.com [ Formatted comment, fixed typo and removed spurious empty line. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-07-31rust: firmware: fix invalid rustdoc linkAndrew Ballance
remove an extra quote from the doc comment so that rustdoc no longer genertes a link to a nonexistent file. Signed-off-by: Andrew Ballance <andrewjballance@gmail.com> Reviewed-by: Danilo Krummrich <dakr@redhat.com> Acked-by: Miguel Ojeda <ojeda@kernel.org> Fixes: de6582833db0 ("rust: add firmware abstractions") Link: https://lore.kernel.org/r/20240709004426.44854-1-andrewjballance@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-29rust: macros: indent list item in `module!`'s docsMiguel Ojeda
Like commit e516211f615f ("rust: macros: indent list item in `paste!`'s docs"), but for `module!`. Reviewed-by: Trevor Gross <tmgross@umich.edu> Link: https://lore.kernel.org/r/20240725184644.135185-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-07-27Merge tag 'rust-6.11' of https://github.com/Rust-for-Linux/linuxLinus Torvalds
Pull Rust updates from Miguel Ojeda: "The highlight is the establishment of a minimum version for the Rust toolchain, including 'rustc' (and bundled tools) and 'bindgen'. The initial minimum will be the pinned version we currently have, i.e. we are just widening the allowed versions. That covers three stable Rust releases: 1.78.0, 1.79.0, 1.80.0 (getting released tomorrow), plus beta, plus nightly. This should already be enough for kernel developers in distributions that provide recent Rust compiler versions routinely, such as Arch Linux, Debian Unstable (outside the freeze period), Fedora Linux, Gentoo Linux (especially the testing channel), Nix (unstable) and openSUSE Slowroll and Tumbleweed. In addition, the kernel is now being built-tested by Rust's pre-merge CI. That is, every change that is attempting to land into the Rust compiler is tested against the kernel, and it is merged only if it passes. Similarly, the bindgen tool has agreed to build the kernel in their CI too. Thus, with the pre-merge CI in place, both projects hope to avoid unintentional changes to Rust that break the kernel. This means that, in general, apart from intentional changes on their side (that we will need to workaround conditionally on our side), the upcoming Rust compiler versions should generally work. In addition, the Rust project has proposed getting the kernel into stable Rust (at least solving the main blockers) as one of its three flagship goals for 2024H2 [1]. I would like to thank Niko, Sid, Emilio et al. for their help promoting the collaboration between Rust and the kernel. Toolchain and infrastructure: - Support several Rust toolchain versions. - Support several bindgen versions. - Remove 'cargo' requirement and simplify 'rusttest', thanks to 'alloc' having been dropped last cycle. - Provide proper error reporting for the 'rust-analyzer' target. 'kernel' crate: - Add 'uaccess' module with a safe userspace pointers abstraction. - Add 'page' module with a 'struct page' abstraction. - Support more complex generics in workqueue's 'impl_has_work!' macro. 'macros' crate: - Add 'firmware' field support to the 'module!' macro. - Improve 'module!' macro documentation. Documentation: - Provide instructions on what packages should be installed to build the kernel in some popular Linux distributions. - Introduce the new kernel.org LLVM+Rust toolchains. - Explain '#[no_std]'. And a few other small bits" Link: https://rust-lang.github.io/rust-project-goals/2024h2/index.html#flagship-goals [1] * tag 'rust-6.11' of https://github.com/Rust-for-Linux/linux: (26 commits) docs: rust: quick-start: add section on Linux distributions rust: warn about `bindgen` versions 0.66.0 and 0.66.1 rust: start supporting several `bindgen` versions rust: work around `bindgen` 0.69.0 issue rust: avoid assuming a particular `bindgen` build rust: start supporting several compiler versions rust: simplify Clippy warning flags set rust: relax most deny-level lints to warnings rust: allow `dead_code` for never constructed bindings rust: init: simplify from `map_err` to `inspect_err` rust: macros: indent list item in `paste!`'s docs rust: add abstraction for `struct page` rust: uaccess: add typed accessors for userspace pointers uaccess: always export _copy_[from|to]_user with CONFIG_RUST rust: uaccess: add userspace pointers kbuild: rust-analyzer: improve comment documentation kbuild: rust-analyzer: better error handling docs: rust: no_std is used rust: alloc: add __GFP_HIGHMEM flag rust: alloc: fix typo in docs for GFP_NOWAIT ...
2024-07-25Merge tag 'uml-for-linus-6.11-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/uml/linux Pull UML updates from Richard Weinberger: - Support for preemption - i386 Rust support - Huge cleanup by Benjamin Berg - UBSAN support - Removal of dead code * tag 'uml-for-linus-6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/uml/linux: (41 commits) um: vector: always reset vp->opened um: vector: remove vp->lock um: register power-off handler um: line: always fill *error_out in setup_one_line() um: remove pcap driver from documentation um: Enable preemption in UML um: refactor TLB update handling um: simplify and consolidate TLB updates um: remove force_flush_all from fork_handler um: Do not flush MM in flush_thread um: Delay flushing syscalls until the thread is restarted um: remove copy_context_skas0 um: remove LDT support um: compress memory related stub syscalls while adding them um: Rework syscall handling um: Add generic stub_syscall6 function um: Create signal stack memory assignment in stub_data um: Remove stub-data.h include from common-offsets.h um: time-travel: fix signal blocking race/hang um: time-travel: remove time_exit() ...
2024-07-25Merge tag 'driver-core-6.11-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core updates from Greg KH: "Here is the big set of driver core changes for 6.11-rc1. Lots of stuff in here, with not a huge diffstat, but apis are evolving which required lots of files to be touched. Highlights of the changes in here are: - platform remove callback api final fixups (Uwe took many releases to get here, finally!) - Rust bindings for basic firmware apis and initial driver-core interactions. It's not all that useful for a "write a whole driver in rust" type of thing, but the firmware bindings do help out the phy rust drivers, and the driver core bindings give a solid base on which others can start their work. There is still a long way to go here before we have a multitude of rust drivers being added, but it's a great first step. - driver core const api changes. This reached across all bus types, and there are some fix-ups for some not-common bus types that linux-next and 0-day testing shook out. This work is being done to help make the rust bindings more safe, as well as the C code, moving toward the end-goal of allowing us to put driver structures into read-only memory. We aren't there yet, but are getting closer. - minor devres cleanups and fixes found by code inspection - arch_topology minor changes - other minor driver core cleanups All of these have been in linux-next for a very long time with no reported problems" * tag 'driver-core-6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (55 commits) ARM: sa1100: make match function take a const pointer sysfs/cpu: Make crash_hotplug attribute world-readable dio: Have dio_bus_match() callback take a const * zorro: make match function take a const pointer driver core: module: make module_[add|remove]_driver take a const * driver core: make driver_find_device() take a const * driver core: make driver_[create|remove]_file take a const * firmware_loader: fix soundness issue in `request_internal` firmware_loader: annotate doctests as `no_run` devres: Correct code style for functions that return a pointer type devres: Initialize an uninitialized struct member devres: Fix memory leakage caused by driver API devm_free_percpu() devres: Fix devm_krealloc() wasting memory driver core: platform: Switch to use kmemdup_array() driver core: have match() callback in struct bus_type take a const * MAINTAINERS: add Rust device abstractions to DRIVER CORE device: rust: improve safety comments MAINTAINERS: add Danilo as FIRMWARE LOADER maintainer MAINTAINERS: add Rust FW abstractions to FIRMWARE LOADER firmware: rust: improve safety comments ...
2024-07-18Merge tag 'slab-for-6.11' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab Pull slab updates from Vlastimil Babka: "The most prominent change this time is the kmem_buckets based hardening of kmalloc() allocations from Kees Cook. We have also extended the kmalloc() alignment guarantees for non-power-of-two sizes in a way that benefits rust. The rest are various cleanups and non-critical fixups. - Dedicated bucket allocator (Kees Cook) This series [1] enhances the probabilistic defense against heap spraying/grooming of CONFIG_RANDOM_KMALLOC_CACHES from last year. kmalloc() users that are known to be useful for exploits can get completely separate set of kmalloc caches that can't be shared with other users. The first converted users are alloc_msg() and memdup_user(). The hardening is enabled by CONFIG_SLAB_BUCKETS. - Extended kmalloc() alignment guarantees (Vlastimil Babka) For years now we have guaranteed natural alignment for power-of-two allocations, but nothing was defined for other sizes (in practice, we have two such buckets, kmalloc-96 and kmalloc-192). To avoid unnecessary padding in the rust layer due to its alignment rules, extend the guarantee so that the alignment is at least the largest power-of-two divisor of the requested size. This fits what rust needs, is a superset of the existing power-of-two guarantee, and does not in practice change the layout (and thus does not add overhead due to padding) of the kmalloc-96 and kmalloc-192 caches, unless slab debugging is enabled for them. - Cleanups and non-critical fixups (Chengming Zhou, Suren Baghdasaryan, Matthew Willcox, Alex Shi, and Vlastimil Babka) Various tweaks related to the new alloc profiling code, folio conversion, debugging and more leftovers after SLAB" Link: https://lore.kernel.org/all/20240701190152.it.631-kees@kernel.org/ [1] * tag 'slab-for-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab: mm/memcg: alignment memcg_data define condition mm, slab: move prepare_slab_obj_exts_hook under CONFIG_MEM_ALLOC_PROFILING mm, slab: move allocation tagging code in the alloc path into a hook mm/util: Use dedicated slab buckets for memdup_user() ipc, msg: Use dedicated slab buckets for alloc_msg() mm/slab: Introduce kmem_buckets_create() and family mm/slab: Introduce kvmalloc_buckets_node() that can take kmem_buckets argument mm/slab: Plumb kmem_buckets into __do_kmalloc_node() mm/slab: Introduce kmem_buckets typedef slab, rust: extend kmalloc() alignment guarantees to remove Rust padding slab: delete useless RED_INACTIVE and RED_ACTIVE slab: don't put freepointer outside of object if only orig_size slab: make check_object() more consistent mm: Reduce the number of slab->folio casts mm, slab: don't wrap internal functions with alloc_hooks()
2024-07-15Merge tag 'for-6.11/block-20240710' of git://git.kernel.dk/linuxLinus Torvalds
Pull block updates from Jens Axboe: - NVMe updates via Keith: - Device initialization memory leak fixes (Keith) - More constants defined (Weiwen) - Target debugfs support (Hannes) - PCIe subsystem reset enhancements (Keith) - Queue-depth multipath policy (Redhat and PureStorage) - Implement get_unique_id (Christoph) - Authentication error fixes (Gaosheng) - MD updates via Song - sync_action fix and refactoring (Yu Kuai) - Various small fixes (Christoph Hellwig, Li Nan, and Ofir Gal, Yu Kuai, Benjamin Marzinski, Christophe JAILLET, Yang Li) - Fix loop detach/open race (Gulam) - Fix lower control limit for blk-throttle (Yu) - Add module descriptions to various drivers (Jeff) - Add support for atomic writes for block devices, and statx reporting for same. Includes SCSI and NVMe (John, Prasad, Alan) - Add IO priority information to block trace points (Dongliang) - Various zone improvements and tweaks (Damien) - mq-deadline tag reservation improvements (Bart) - Ignore direct reclaim swap writes in writeback throttling (Baokun) - Block integrity improvements and fixes (Anuj) - Add basic support for rust based block drivers. Has a dummy null_blk variant for now (Andreas) - Series converting driver settings to queue limits, and cleanups and fixes related to that (Christoph) - Cleanup for poking too deeply into the bvec internals, in preparation for DMA mapping API changes (Christoph) - Various minor tweaks and fixes (Jiapeng, John, Kanchan, Mikulas, Ming, Zhu, Damien, Christophe, Chaitanya) * tag 'for-6.11/block-20240710' of git://git.kernel.dk/linux: (206 commits) floppy: add missing MODULE_DESCRIPTION() macro loop: add missing MODULE_DESCRIPTION() macro ublk_drv: add missing MODULE_DESCRIPTION() macro xen/blkback: add missing MODULE_DESCRIPTION() macro block/rnbd: Constify struct kobj_type block: take offset into account in blk_bvec_map_sg again block: fix get_max_segment_size() warning loop: Don't bother validating blocksize virtio_blk: Don't bother validating blocksize null_blk: Don't bother validating blocksize block: Validate logical block size in blk_validate_limits() virtio_blk: Fix default logical block size fallback nvmet-auth: fix nvmet_auth hash error handling nvme: implement ->get_unique_id block: pass a phys_addr_t to get_max_segment_size block: add a bvec_phys helper blk-lib: check for kill signal in ioctl BLKZEROOUT block: limit the Write Zeroes to manually writing zeroes fallback block: refacto blkdev_issue_zeroout block: move read-only and supported checks into (__)blkdev_issue_zeroout ...
2024-07-15Merge branch 'slab/for-6.11/buckets' into slab/for-nextVlastimil Babka
Merge all the slab patches previously collected on top of v6.10-rc1, over cleanups/fixes that had to be based on rc6.
generated by cgit (git 2.34.1) at 2025-07-15 05:41:31 +0000