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

Need confirmation on whether high-risk lines produce deadlock #5482

Closed
4 tasks
amab8901 opened this issue Feb 19, 2023 · 1 comment
Closed
4 tasks

Need confirmation on whether high-risk lines produce deadlock #5482

amab8901 opened this issue Feb 19, 2023 · 1 comment
Labels
A-tokio Area: The main tokio crate C-bug Category: This is a bug. M-sync Module: tokio/sync

Comments

@amab8901
Copy link
Contributor

amab8901 commented Feb 19, 2023

These lines were identified (#5479) as having high probability of producing deadlocks (as in #5429):

  • task/atomic_waker.rs
    • 204
  • broadcast.rs
    • 915
  • notify.rs
    • 771
    • 835
    • 874
  • oneshot.rs
    • 427

I think we need to create some kind of tests to verify whether they actually can cause deadlocks.

@amab8901 amab8901 added A-tokio Area: The main tokio crate C-bug Category: This is a bug. labels Feb 19, 2023
@Darksonn Darksonn added the M-sync Module: tokio/sync label Feb 19, 2023
@Darksonn
Copy link
Contributor

I took a look at them:

  1. task/atomic_waker.rs - this one already handles panics correctly, and there's no mutex so it cannot deadlock
  2. broadcast.rs - This assignment only happens if the field is None, so it cannot run the destructor of a waker.
  3. notify.rs - will be fixed by #5471
  4. oneshot.rs - This uses ptr.write, which doesn't run the destructor of old values, so it isn't vulnerable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tokio Area: The main tokio crate C-bug Category: This is a bug. M-sync Module: tokio/sync
Projects
None yet
Development

No branches or pull requests

2 participants