Skip to content
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

Merged

Conversation

MarkusPettersson98
Copy link
Contributor

@MarkusPettersson98 MarkusPettersson98 commented Sep 24, 2024

This PR consolidates two mutexes found in the ApiAvailability struct into a single one. We managed to run into a deadlock once where mullvad-daemon would not progress from the Disconnecting 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 in ApiAvailability by consolidating multiple mutexes into a single one.


This change is Reviewable

Copy link

linear bot commented Sep 24, 2024

@MarkusPettersson98 MarkusPettersson98 force-pushed the daemon-stuck-in-disconnecting-state-des-1263 branch 2 times, most recently from 9eedf9b to bb10ecc Compare September 25, 2024 08:27
dlon
dlon previously approved these changes Sep 25, 2024
Copy link
Member

@dlon dlon left a 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?

Copy link
Contributor Author

@MarkusPettersson98 MarkusPettersson98 left a 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:)

Copy link
Member

@dlon dlon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

Reviewed 2 of 2 files at r2, all commit messages.
Reviewable status: :shipit: complete! all files reviewed, all discussions resolved

@MarkusPettersson98 MarkusPettersson98 force-pushed the daemon-stuck-in-disconnecting-state-des-1263 branch from ddbf193 to aeab100 Compare September 25, 2024 11:08
@MarkusPettersson98 MarkusPettersson98 merged commit a6c6d5d into main Sep 25, 2024
52 checks passed
@MarkusPettersson98 MarkusPettersson98 deleted the daemon-stuck-in-disconnecting-state-des-1263 branch September 25, 2024 11:27
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 this pull request may close these issues.

2 participants