Support dynamically allocated lockdep keys #1102
Comments
fbq
added
• lib
|
Looking into getting a patch out for this |
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this issue
Dec 19, 2024
Reintroduce dynamically-allocated LockClassKeys such that they are automatically (de)registered. Require that all usages of LockClassKeys ensure that they are Pin'd. Closes: Rust-for-Linux#1102 Suggested-by: Benno Lossin <[email protected]> Suggested-by: Boqun Feng <[email protected]> Signed-off-by: Mitchell Levy <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this issue
Feb 5, 2025
Reintroduce dynamically-allocated LockClassKeys such that they are automatically (de)registered. Require that all usages of LockClassKeys ensure that they are Pin'd. Closes: Rust-for-Linux#1102 Suggested-by: Benno Lossin <[email protected]> Suggested-by: Boqun Feng <[email protected]> Signed-off-by: Mitchell Levy <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this issue
Feb 8, 2025
Reintroduce dynamically-allocated LockClassKeys such that they are automatically (de)registered. Require that all usages of LockClassKeys ensure that they are Pin'd. Currently, only `'static` LockClassKeys are supported, so Pin is redundant. However, it is intended that dynamically-allocated LockClassKeys will eventually be supported, so using Pin from the outset will make that change simpler. Closes: Rust-for-Linux#1102 Suggested-by: Benno Lossin <[email protected]> Suggested-by: Boqun Feng <[email protected]> Signed-off-by: Mitchell Levy <[email protected]>
Darksonn
pushed a commit
to Darksonn/linux
that referenced
this issue
Feb 10, 2025
Reintroduce dynamically-allocated LockClassKeys such that they are automatically (de)registered. Require that all usages of LockClassKeys ensure that they are Pin'd. Currently, only `'static` LockClassKeys are supported, so Pin is redundant. However, it is intended that dynamically-allocated LockClassKeys will eventually be supported, so using Pin from the outset will make that change simpler. Closes: Rust-for-Linux#1102 Suggested-by: Benno Lossin <[email protected]> Suggested-by: Boqun Feng <[email protected]> Signed-off-by: Mitchell Levy <[email protected]> Reviewed-by: Benno Lossin <[email protected]> Signed-off-by: Boqun Feng <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, there's a design hole which allows users to pass an unregistered lockdep key to a C function that expects a registered one: example. We can fix this by:
&LockClassKeywithPin<&LockClassKey>in all lock APIs to reflect that the lock keys need address stability to work.LockClassKey, which registers the key at the initialization time.LockClassKey, which unregisters the key.static_lock_class!()still work by creating aPin<&'static LockClassKey>from a static uninit variable (as long as it's static allocated, lockdep supports the uninitialized key).Detailed discussions can be found: https://lore.kernel.org/rust-for-linux/[email protected]/
The text was updated successfully, but these errors were encountered: