-
Notifications
You must be signed in to change notification settings - Fork 402
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mutex::lock_noguard() may be unsafe #862
Comments
Very cool find, @fbq ! I'm not a big fan of the idea of having extra atomic incs/decs on the lock/unlock paths as that would clearly make the Rust version more expensive. We may have to do it though if we can't find another way of dealing with this. Let me think about this for a bit. |
I share the same worry about having extra atomic incs/decs. Maybe we just make |
I think the |
Ah, you are right. |
As seen in Rust-for-Linux#862 it is unsound to `mem::forget` a guard of a Mutex, because the C mutex sets the thread owner. It also is a footgun to send a `Guard` of a `Spinlock` to another thread (as doing so might result in the spinlock being locked while the other thread is sleeping). It is a conservative decision to make all guard contexts `!Send`, this can be lifted in the future. Signed-off-by: Benno Lossin <y86-dev@protomail.com> Co-authored-by: Miguel Ojeda <ojeda@users.noreply.github.com>
As seen in Rust-for-Linux#862 it is unsound to `mem::forget` a guard of a Mutex, because the C mutex sets the thread owner. It also is a footgun to send a `Guard` of a `Spinlock` to another thread (as doing so might result in the spinlock being locked while the other thread is sleeping). It is a conservative decision to make all guard contexts `!Send`, this can be lifted in the future. Link: Rust-for-Linux#862 Signed-off-by: Benno Lossin <y86-dev@protomail.com>
As seen in [1] it is unsound to `mem::forget` a guard of a Mutex, because the C mutex sets the thread owner. Similarly it is a footgun to send a `Guard<Spinlock>` to another thread (as doing so might result in the spinlock being locked while the other thread is sleeping). It is a conservative decision to prevent sending any `Guard` to another thread. Link: Rust-for-Linux#862 [1] Signed-off-by: Benno Lossin <y86-dev@protonmail.com>
This is a generic lock guard. It is written as a generic type because the kernel has several locking primitives, and using a single guard type allows for code reuse and for primitives like condition variables to work on any locks that satisfy the `Lock` trait. Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
@wedsonaf This came to me when I'm investigating the safety of
schedule
.Linux's
mutex_lock()
sets->lock
to the current task once the lock is grabbed. If another thread tries to grab the lock, instead of sleeping immediately, it will check whether the lock owner is on cpu or not (mutex
is a sleepable lock) viatask_struct::on_cpu
. And if the task is running on some CPU, the owner may finish its work soon and release the lock, so the other thread will spin instead of sleep.Consider the following case
This means
Mutex::lock_noguard()
is unsafe, and the safety guarantee would be making sure that a thread releases the lock before exiting or #863 is neededThe text was updated successfully, but these errors were encountered: