user/sven/linux.git/rust, branch v6.15.7

rust: devres: do not dereference to the internal Revocable

2025-07-06T09:04:25Z

commit 20c96ed278e362ae4e324ed7d8c69fb48c508d3c upstream. We can't expose direct access to the internal Revocable, since this allows users to directly revoke the internal Revocable without Devres having the chance to synchronize with the devres callback -- we have to guarantee that the internal Revocable has been fully revoked before the device is fully unbound. Hence, remove the corresponding Deref implementation and, instead, provide indirect accessors for the internal Revocable. Note that we can still support Devres::revoke() by implementing the required synchronization (which would be almost identical to the synchronization in Devres::drop()). Fixes: 76c01ded724b ("rust: add devres abstraction") Reviewed-by: Benno Lossin Link: https://lore.kernel.org/r/20250611174827.380555-1-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman

rust: devres: fix race in Devres::drop()

2025-07-06T09:04:25Z

commit f744201c6159fc7323c40936fd079525f7063598 upstream. In Devres::drop() we first remove the devres action and then drop the wrapped device resource. The design goal is to give the owner of a Devres object control over when the device resource is dropped, but limit the overall scope to the corresponding device being bound to a driver. However, there's a race that was introduced with commit 8ff656643d30 ("rust: devres: remove action in `Devres::drop`"), but also has been (partially) present from the initial version on. In Devres::drop(), the devres action is removed successfully and subsequently the destructor of the wrapped device resource runs. However, there is no guarantee that the destructor of the wrapped device resource completes before the driver core is done unbinding the corresponding device. If in Devres::drop(), the devres action can't be removed, it means that the devres callback has been executed already, or is still running concurrently. In case of the latter, either Devres::drop() wins revoking the Revocable or the devres callback wins revoking the Revocable. If Devres::drop() wins, we (again) have no guarantee that the destructor of the wrapped device resource completes before the driver core is done unbinding the corresponding device. CPU0 CPU1 ------------------------------------------------------------------------ Devres::drop() { Devres::devres_callback() { self.data.revoke() { this.data.revoke() { is_available.swap() == true is_available.swap == false } } // [...] // device fully unbound drop_in_place() { // release device resource } } } Depending on the specific device resource, this can potentially lead to user-after-free bugs. In order to fix this, implement the following logic. In the devres callback, we're always good when we get to revoke the device resource ourselves, i.e. Revocable::revoke() returns true. If Revocable::revoke() returns false, it means that Devres::drop(), concurrently, already drops the device resource and we have to wait for Devres::drop() to signal that it finished dropping the device resource. Note that if we hit the case where we need to wait for the completion of Devres::drop() in the devres callback, it means that we're actually racing with a concurrent Devres::drop() call, which already started revoking the device resource for us. This is rather unlikely and means that the concurrent Devres::drop() already started doing our work and we just need to wait for it to complete it for us. Hence, there should not be any additional overhead from that. (Actually, for now it's even better if Devres::drop() does the work for us, since it can bypass the synchronize_rcu() call implied by Revocable::revoke(), but this goes away anyways once I get to implement the split devres callback approach, which allows us to first flip the atomics of all registered Devres objects of a certain device, execute a single synchronize_rcu() and then drop all revocable objects.) In Devres::drop() we try to revoke the device resource. If that is *not* successful, it means that the devres callback already did and we're good. Otherwise, we try to remove the devres action, which, if successful, means that we're good, since the device resource has just been revoked by us *before* we removed the devres action successfully. If the devres action could not be removed, it means that the devres callback must be running concurrently, hence we signal that the device resource has been revoked by us, using the completion. This makes it safe to drop a Devres object from any task and at any point of time, which is one of the design goals. Fixes: 76c01ded724b ("rust: add devres abstraction") Reported-by: Alice Ryhl Closes: https://lore.kernel.org/lkml/aD64YNuqbPPZHAa5@google.com/ Reviewed-by: Benno Lossin Link: https://lore.kernel.org/r/20250612121817.1621-4-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman

rust: revocable: indicate whether `data` has been revoked already

2025-07-06T09:04:25Z

commit 4b76fafb20dd4a2becb94949d78e86bc88006509 upstream. Return a boolean from Revocable::revoke() and Revocable::revoke_nosync() to indicate whether the data has been revoked already. Return true if the data hasn't been revoked yet (i.e. this call revoked the data), false otherwise. This is required by Devres in order to synchronize the completion of the revoke process. Reviewed-by: Benno Lossin Acked-by: Miguel Ojeda Link: https://lore.kernel.org/r/20250612121817.1621-3-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman

rust: completion: implement initial abstraction

2025-07-06T09:04:25Z

commit 1b56e765bf8990f1f60e124926c11fc4ac63d752 upstream. Implement a minimal abstraction for the completion synchronization primitive. This initial abstraction only adds complete_all() and wait_for_completion(), since that is what is required for the subsequent Devres patch. Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Juri Lelli Cc: Vincent Guittot Cc: Dietmar Eggemann Cc: Steven Rostedt Cc: Ben Segall Cc: Mel Gorman Cc: Valentin Schneider Reviewed-by: Alice Ryhl Reviewed-by: Boqun Feng Reviewed-by: Benno Lossin Acked-by: Miguel Ojeda Link: https://lore.kernel.org/r/20250612121817.1621-2-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman

rust: arm: fix unknown (to Clang) argument '-mno-fdpic'

2025-07-06T09:04:05Z

[ Upstream commit 977c4308ee4270cf46e2c66b37de8e04670daa0c ] Currently rust on arm fails to compile due to '-mno-fdpic'. This flag disables a GCC feature that we don't want for kernel builds, so let's skip it as it doesn't apply to Clang. UPD include/generated/asm-offsets.h CALL scripts/checksyscalls.sh RUSTC L rust/core.o BINDGEN rust/bindings/bindings_generated.rs BINDGEN rust/bindings/bindings_helpers_generated.rs CC rust/helpers/helpers.o Unable to generate bindings: clang diagnosed error: error: unknown argument: '-mno-fdpic' make[2]: *** [rust/Makefile:369: rust/bindings/bindings_helpers_generated.rs] Error 1 make[2]: *** Deleting file 'rust/bindings/bindings_helpers_generated.rs' make[2]: *** Waiting for unfinished jobs.... Unable to generate bindings: clang diagnosed error: error: unknown argument: '-mno-fdpic' make[2]: *** [rust/Makefile:349: rust/bindings/bindings_generated.rs] Error 1 make[2]: *** Deleting file 'rust/bindings/bindings_generated.rs' make[1]: *** [/home/pmos/build/src/linux-next-next-20250521/Makefile:1285: prepare] Error 2 make: *** [Makefile:248: __sub-make] Error 2 [ Naresh provided the draft diff [1]. Ben explained [2]: FDPIC is only relevant with no-MMU targets, and then only for userspace. When configured for the arm-*-uclinuxfdpiceabi target, GCC enables FDPIC by default to facilitate compiling userspace programs. FDPIC is never used for the kernel, and we pass -mno-fdpic when building the kernel to override the default and make sure FDPIC is disabled. and [3]: -mno-fdpic disables a GCC feature that we don't want for kernel builds. clang does not support this feature, so it always behaves as though -mno-fdpic is passed. Therefore, it should be fine to mix the two, at least as far as FDPIC is concerned. [1] https://lore.kernel.org/rust-for-linux/CA+G9fYt4otQK4pHv8pJBW9e28yHSGCDncKquwuJiJ_1ou0pq0w@mail.gmail.com/ [2] https://lore.kernel.org/rust-for-linux/aAKrq2InExQk7f_k@dell-precision-5540/ [3] https://lore.kernel.org/rust-for-linux/aAo_F_UP1Gd4jHlZ@dell-precision-5540/ - Miguel ] Reported-by: Linux Kernel Functional Testing Closes: https://lore.kernel.org/all/CA+G9fYvOanQBYXKSg7C6EU30k8sTRC0JRPJXYu7wWK51w38QUQ@mail.gmail.com/ Suggested-by: Miguel Ojeda Acked-by: Naresh Kamboju Signed-off-by: Rudraksha Gupta Link: https://lore.kernel.org/r/20250522-rust-mno-fdpic-arm-fix-v2-1-a6f691d9c198@gmail.com [ Reworded title. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin

rust: module: place cleanup_module() in .exit.text section

2025-07-06T09:04:05Z

[ Upstream commit 249c3a0e53acefc2b06d3b3e1fc28fb2081f878d ] Place cleanup_module() in .exit.text section. Currently, cleanup_module() is likely placed in the .text section. It's inconsistent with the layout of C modules, where cleanup_module() is placed in .exit.text. [ Boqun asked for an example of how the section changed to be put in the log. Tomonori provided the following examples: C module: $ objdump -t ~/build/x86/drivers/block/loop.o|grep clean 0000000000000000 l O .exit.data 0000000000000008 __UNIQUE_ID___addressable_cleanup_module412 0000000000000000 g F .exit.text 000000000000009c cleanup_module Rust module without this patch: $ objdump -t ~/build/x86/samples/rust/rust_minimal.o|grep clean 00000000000002b0 g F .text 00000000000000c6 cleanup_module 0000000000000000 g O .exit.data 0000000000000008 _R...___UNIQUE_ID___addressable_cleanup_module Rust module with this patch: $ objdump -t ~/build/x86/samples/rust/rust_minimal.o|grep clean 0000000000000000 g F .exit.text 00000000000000c6 cleanup_module 0000000000000000 g O .exit.data 0000000000000008 _R...___UNIQUE_ID___addressable_cleanup_module - Miguel ] Signed-off-by: FUJITA Tomonori Acked-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20250308044506.14458-1-fujita.tomonori@gmail.com Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin

rust: list: fix path of `assert_pinned!`

2025-06-19T13:41:02Z

commit eb71feaacaaca227ae8f91c8578cf831553c5ab5 upstream. Commit dbd5058ba60c ("rust: make pin-init its own crate") moved all items from pin-init into the pin-init crate, including the `assert_pinned!` macro. Thus fix the path of the sole user of the `assert_pinned!` macro. This occurrence was missed in the commit above, since it is in a macro rule that has no current users (although binder is a future user). Cc: stable@kernel.org Fixes: dbd5058ba60c ("rust: make pin-init its own crate") Signed-off-by: Benno Lossin Link: https://lore.kernel.org/r/20250525173450.853413-1-lossin@kernel.org [ Reworded slightly as discussed in the list. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

rust: compile libcore with edition 2024 for 1.87+

2025-06-19T13:41:02Z

commit f4daa80d6be7d3c55ca72a8e560afc4e21f886aa upstream. Rust 1.87 (released on 2025-05-15) compiles core library with edition 2024 instead of 2021 [1]. Ensure that the edition matches libcore's expectation to avoid potential breakage. [ J3m3 reported in Zulip [2] that the `rust-analyzer` target was broken after this patch -- indeed, we need to avoid `core-cfgs` since those are passed to the `rust-analyzer` target. So, instead, I tweaked the patch to create a new `core-edition` variable and explicitly mention the `--edition` flag instead of reusing `core-cfg`s. In addition, pass a new argument using this new variable to `generate_rust_analyzer.py` so that we set the right edition there. By the way, for future reference: the `filter-out` change is needed for Rust < 1.87, since otherwise we would skip the `--edition=2021` we just added, ending up with no edition flag, and thus the compiler would default to the 2015 one. [2] https://rust-for-linux.zulipchat.com/#narrow/channel/291565/topic/x/near/520206547 - Miguel ] Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/138162 [1] Reported-by: est31 Closes: https://github.com/Rust-for-Linux/linux/issues/1163 Signed-off-by: Gary Guo Link: https://lore.kernel.org/r/20250517085600.2857460-1-gary@garyguo.net Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

rust: miscdevice: fix typo in MiscDevice::ioctl documentation

2025-06-19T13:40:33Z

[ Upstream commit 81e9edc1a8d657291409d70d93361d8277d226d8 ] Fixes one small typo (`utilties` to `utilities`) in the documentation of `MiscDevice::ioctl`. Fixes: f893691e7426 ("rust: miscdevice: add base miscdevice abstraction") Signed-off-by: Christian Schrefl Reviewed-by: Benno Lossin Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20250517-rust_miscdevice_fix_typo-v1-1-8c30a6237ba9@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

rust: pci: fix docs related to missing Markdown code spans

2025-06-19T13:40:29Z

[ Upstream commit 1dbaf8b1bafb8557904eb54b98bb323a3061dd2c ] In particular: - Add missing Markdown code spans. - Improve title for `DeviceId`, adding a link to the struct in the C side, rather than referring to `bindings::`. - Convert `TODO` from documentation to a normal comment, and put code in block. This was found using the Clippy `doc_markdown` lint, which we may want to enable. Fixes: 1bd8b6b2c5d3 ("rust: pci: add basic PCI device / driver abstractions") Reviewed-by: Benno Lossin Acked-by: Danilo Krummrich Link: https://lore.kernel.org/r/20250324210359.1199574-8-ojeda@kernel.org [ Prefixed link text with `struct`. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin