Skip to content

Rwlock handles recursive locking attempts poorly on linux (double unlock) #25012

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

Closed
talchas opened this issue Apr 30, 2015 · 0 comments · Fixed by #25015
Closed

Rwlock handles recursive locking attempts poorly on linux (double unlock) #25012

talchas opened this issue Apr 30, 2015 · 0 comments · Fixed by #25015

Comments

@talchas
Copy link

talchas commented Apr 30, 2015

On linux pthread_rwlock_rdlock/wrlock return EDEADLK if you attempt to take the other type of lock when you own one. libstd ignores this when debug-assertions are not on, and then will try to unlock twice anyway. This leads to arbitrarily bad behavior (on playpen it happens to hit x86-HLE code and SIGILL):

use std::sync::RwLock;
fn main() {
    let x = RwLock::new("");
    let _w = x.write().unwrap();
    let _r = x.read().unwrap();
}
alexcrichton added a commit to alexcrichton/rust that referenced this issue Apr 30, 2015
Apparently implementations are allowed to return EDEADLK instead of blocking
forever, in which case this can lead to unsafety in the `RwLock` primitive
exposed by the standard library. A debug-build of the standard library would
have caught this error (due to the debug assert), but we don't ship debug
builds right now.

This commit adds explicit checks for the EDEADLK error code and triggers a panic
to ensure the call does not succeed.

Closes rust-lang#25012
bors added a commit that referenced this issue May 2, 2015
Apparently implementations are allowed to return EDEADLK instead of blocking
forever, in which case this can lead to unsafety in the `RwLock` primitive
exposed by the standard library. A debug-build of the standard library would
have caught this error (due to the debug assert), but we don't ship debug
builds right now.

This commit adds explicit checks for the EDEADLK error code and triggers a panic
to ensure the call does not succeed.

Closes #25012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant