linux.git/rust/kernel/sync/lock/spinlock.rs, branch v7.3-rc2

rust: sync: Introduce SpinLockIrq::lock_with() and friends

2026-08-10T10:53:11+00:00

`SpinLockIrq` and `SpinLock` use the exact same underlying C structure,
with the only real difference being that the former uses the
irq_disable() and irq_enable() variants for locking/unlocking. These
variants can introduce some minor overhead in contexts where we already
know that local processor interrupts are disabled, and as such we want a
way to be able to skip modifying processor interrupt state in said
contexts in order to avoid some overhead - just like the current C API
allows us to do.

In order to do this, we add some special functions for SpinLockIrq:
lock_with() and try_lock_with(), which allow acquiring the lock without
changing the interrupt state - as long as the caller can provide a
LocalInterruptDisabled reference to prove that local processor
interrupts have been disabled.

In some hacked-together benchmarks we ran, most of the time this did
actually seem to lead to a noticeable difference in overhead:

  From an aarch64 VM running on a MacBook M4:
    lock() when irq is disabled, 100 times cost Delta { nanos: 500 }
    lock_with() when irq is disabled, 100 times cost Delta { nanos: 292 }
    lock() when irq is enabled, 100 times cost Delta { nanos: 834 }

    lock() when irq is disabled, 100 times cost Delta { nanos: 459 }
    lock_with() when irq is disabled, 100 times cost Delta { nanos: 291 }
    lock() when irq is enabled, 100 times cost Delta { nanos: 709 }

  From an x86_64 VM (qemu/kvm) running on a i7-13700H
    lock() when irq is disabled, 100 times cost Delta { nanos: 1002 }
    lock_with() when irq is disabled, 100 times cost Delta { nanos: 729 }
    lock() when irq is enabled, 100 times cost Delta { nanos: 1516 }

    lock() when irq is disabled, 100 times cost Delta { nanos: 754 }
    lock_with() when irq is disabled, 100 times cost Delta { nanos: 966 }
    lock() when irq is enabled, 100 times cost Delta { nanos: 1227 }

    (note that there were some runs on x86_64 where lock() on irq
    disabled vs. lock_with() on irq disabled had equivalent benchmarks,
    but it very much appeared to be a minority of test runs.)

While it's not clear how this affects real-world workloads yet, let's
add this for the time being so we can find out.

This makes it so that a `SpinLockIrq` will work like a `SpinLock` if
interrupts are disabled. So a function:

        (&'a SpinLockIrq, &'a LocalInterruptDisabled) -> Guard<'a, .., SpinLockBackend>

makes sense. Note that due to `Guard` and `LocalInterruptDisabled`
having the same lifetime, interrupts cannot be enabled while the Guard
exists.

Signed-off-by: Lyude Paul 
Signed-off-by: Boqun Feng 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Gary Guo 
Link: https://patch.msgid.link/20260807070218.27144-19-boqun@kernel.org

rust: sync: Add SpinLockIrq

2026-08-10T10:53:10+00:00

A variant of `SpinLock` that ensures interrupts are disabled in the
critical section. `lock()` will ensure that either interrupts are
already disabled or disable them. `unlock()` will reverse the respective
operation.

[Boqun: Port to use spin_lock_irq_disable() and
spin_unlock_irq_enable()]

Signed-off-by: Lyude Paul 
Signed-off-by: Boqun Feng 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Gary Guo 
Link: https://patch.msgid.link/20260807070218.27144-18-boqun@kernel.org

rust: sync: Use super::* in spinlock.rs

2026-08-10T10:53:10+00:00

No functional changes.

Signed-off-by: Lyude Paul 
Signed-off-by: Boqun Feng 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://patch.msgid.link/20260807070218.27144-17-boqun@kernel.org

rust: sync: Inline various lock related methods

2026-01-10T02:53:46+00:00

While debugging a different issue [1], the following relocation was
noticed in the rust_binder.ko file:

	R_AARCH64_CALL26	_RNvXNtNtNtCsdfZWD8DztAw_6kernel4sync4lock8spinlockNtB2_15SpinLockBackendNtB4_7Backend6unlock

This relocation (and a similar one for lock) occurred many times
throughout the module. That is not really useful because all this
function does is call spin_unlock(), so what we actually want here is
that a call to spin_unlock() dirctly is generated in favor of this
wrapper method.

Thus, mark these methods inline.

[boqun: Reword the commit message a bit]

Link: https://lore.kernel.org/p/20251111-binder-fix-list-remove-v1-0-8ed14a0da63d@google.com
Signed-off-by: Alice Ryhl 
Reviewed-by: Gary Guo 
Reviewed-by: Daniel Almeida 
Signed-off-by: Boqun Feng 
Link: https://patch.msgid.link/20251218-inline-lock-unlock-v2-1-fbadac8bd61b@google.com

rust: make pin-init its own crate

2025-03-16T20:59:19+00:00

Rename relative paths inside of the crate to still refer to the same
items, also rename paths inside of the kernel crate and adjust the build
system to build the crate.

[ Remove the `expect` (and thus the `lint_reasons` feature) since
  the tree now uses `quote!` from `rust/macros/export.rs`. Remove the
  `TokenStream` import removal, since it is now used as well.

  In addition, temporarily (i.e. just for this commit) use an `--extern
  force:alloc` to prevent an unknown `new_uninit` error in the `rustdoc`
  target. For context, please see a similar case in:

      https://lore.kernel.org/lkml/20240422090644.525520-1-ojeda@kernel.org/

  And adjusted the message above. - Miguel ]

Signed-off-by: Benno Lossin 
Reviewed-by: Fiona Behrens 
Tested-by: Andreas Hindborg 
Link: https://lore.kernel.org/r/20250308110339.2997091-16-benno.lossin@proton.me
Signed-off-by: Miguel Ojeda

rust: sync: Add lock::Backend::assert_is_held()

2024-12-19T22:04:42+00:00

Since we've exposed Lock::from_raw() and Guard::new() publically, we
want to be able to make sure that we assert that a lock is actually held
when constructing a Guard for it to handle instances of unsafe
Guard::new() calls outside of our lock module.

Hence add a new method assert_is_held() to Backend, which uses lockdep
to check whether or not a lock has been acquired. When lockdep is
disabled, this has no overhead.

[Boqun: Resolve the conflicts with exposing Guard::new(), reword the
 commit log a bit and format "unsafe { ; }" into "unsafe {
  }" for the consistency. ]

Signed-off-by: Lyude Paul 
Signed-off-by: Boqun Feng 
Link: https://lore.kernel.org/r/20241125204139.656801-1-lyude@redhat.com

rust: sync: Add SpinLockGuard type alias

2024-12-19T22:04:42+00:00

A simple helper alias for code that needs to deal with Guard types returned
from SpinLocks.

Signed-off-by: Lyude Paul 
Reviewed-by: Alice Ryhl 
Signed-off-by: Boqun Feng 
Link: https://lore.kernel.org/r/20241120222742.2490495-3-lyude@redhat.com

rust: use custom FFI integer types

2024-11-10T22:58:00+00:00

Currently FFI integer types are defined in libcore. This commit creates
the `ffi` crate and asks bindgen to use that crate for FFI integer types
instead of `core::ffi`.

This commit is preparatory and no type changes are made in this commit
yet.

Signed-off-by: Gary Guo 
Link: https://lore.kernel.org/r/20240913213041.395655-4-gary@garyguo.net
[ Added `rustdoc`, `rusttest` and KUnit tests support. Rebased on top of
  `rust-next` (e.g. migrated more `core::ffi` cases). Reworded crate
  docs slightly and formatted. - Miguel ]
Signed-off-by: Miguel Ojeda

rust: treewide: switch to our kernel `Box` type

2024-10-15T20:56:59+00:00

Now that we got the kernel `Box` type in place, convert all existing
`Box` users to make use of it.

Reviewed-by: Alice Ryhl 
Reviewed-by: Benno Lossin 
Reviewed-by: Gary Guo 
Signed-off-by: Danilo Krummrich 
Link: https://lore.kernel.org/r/20241004154149.93856-13-dakr@kernel.org
Signed-off-by: Miguel Ojeda

rust: lock: add trylock method support for lock backend

2024-10-09T22:33:42+00:00

Add a non-blocking trylock method to lock backend interface, mutex and
spinlock implementations. It includes a C helper for spin_trylock.

Rust Binder will use this method together with the new shrinker
abstractions to avoid deadlocks in the memory shrinker.

Link: https://lore.kernel.org/all/20240912-shrinker-v1-1-18b7f1253553@google.com
Signed-off-by: Filipe Xavier 
Reviewed-by: Fiona Behrens 
Reviewed-by: Alice Ryhl 
Reviewed-by: Boqun Feng 
Link: https://lore.kernel.org/r/BL0PR02MB4914579914884B5D7473B3D6E96A2@BL0PR02MB4914.namprd02.prod.outlook.com
[ Slightly reworded. - Miguel ]
Signed-off-by: Miguel Ojeda