-
Notifications
You must be signed in to change notification settings - Fork 213
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
Unlock before panicking #1168
Unlock before panicking #1168
Conversation
Move commit info to env var to mitigate run injection vulnerability.
The logic of the function seems like a defer wouldn't unlock in order for that deferred function to handle updating the d.executing state.
What is the goal of this change? what bug/issue does this resolve? |
This is responding to a finding in Semgrep. If we try to recover from this panic, we presumably will still have left that dispatcher locked and wouldn't expect that, so we couldn't properly recover. |
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.
While I think we sometimes lock mutexes we intentionally do not unlock locally, I don't think this is one of those cases. It's just really-old pre-Temporal missed code I think (and highly unlikely these conditions are ever satisfied at runtime).
Will let @Quinn-With-Two-Ns review/merge.
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.
I think if these panics ever trigger the dispatcher should not be used again, but in principle yeah we should unlock
What was changed
Unlock a locked dispatcher mutex before panicking.
Why?
Since it needs to be unlocked to finish running coroutines, and then relocked long enough to have the status changed to not executing, defer didn't fit.
Checklist
How was this tested:
make test is currently failing integration tests