-
Notifications
You must be signed in to change notification settings - Fork 335
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
Avoid potential deadlock in mullvad-api
#6860
Avoid potential deadlock in mullvad-api
#6860
Conversation
9eedf9b
to
bb10ecc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 7 of 7 files at r1, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @MarkusPettersson98)
mullvad-api/src/availability.rs
line 163 at r1 (raw file):
state_ready: impl Fn(State) -> bool, ) -> impl Future<Output = Result<(), Error>> { let mut rx = self.acquire().tx.subscribe();
What do you think of wrapping this in {}
(if clippy is happy with that)? It might just be me but I don't find it obvious that the mutex guard is immediately dropped.
mullvad-api/src/rest.rs
line 187 at r1 (raw file):
async fn process_command(&mut self, command: RequestCommand) { log::debug!("Processing {command:?}");
Should this be removed?
bb10ecc
to
ddbf193
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @dlon)
mullvad-api/src/availability.rs
line 163 at r1 (raw file):
Previously, dlon (David Lönnhager) wrote…
What do you think of wrapping this in
{}
(if clippy is happy with that)? It might just be me but I don't find it obvious that the mutex guard is immediately dropped.
That's fine, I don't mind introducing a local scope to make it more obvious that the mutex guard is dropped. I was a bit unsure as well until I looked it up 😊
mullvad-api/src/rest.rs
line 187 at r1 (raw file):
Previously, dlon (David Lönnhager) wrote…
Should this be removed?
Yes! Thanks:)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 2 of 2 files at r2, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved
ddbf193
to
aeab100
Compare
This PR consolidates two mutexes found in the
ApiAvailability
struct into a single one. We managed to run into a deadlock once wheremullvad-daemon
would not progress from theDisconnecting
state due to us trying to acquire a mutex which was never released by another task. Reproducing the exact issue is of course very hard, but this PR aims to make it easier to reason about deadlocks inApiAvailability
by consolidating multiple mutexes into a single one.This change is