file.c: Fix write-format race when opening a stream for playback - #2040
Draft
jlaine wants to merge 1 commit into
Draft
file.c: Fix write-format race when opening a stream for playback#2040jlaine wants to merge 1 commit into
jlaine wants to merge 1 commit into
Conversation
Contributor
Author
|
@mbradeen I have not yet had a chance to use this patch in production so handle with care. I'm putting it up here to get some feedback on whether the approach is valid. |
github-actions
Bot
added
pr-submit-testing-in-progress
and removed
pr-submit-testing-in-progress
labels
github-actions
Bot
added
pr-submit-testing-in-progress
pr-submit-tests-failed
and removed
pr-submit-testing-in-progress
labels
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
github-actions
Bot
added
the
has-pr-checklist
|
Workflow Check failed |
github-actions
Bot
added
pr-submit-testing-in-progress
and removed
pr-submit-tests-failed
labels
openstream_internal() set the channel write format under the channel lock, released the lock, then re-checked that format in filehelper() (ACTION_OPEN) while holding only the formats RWLIST. The bridging and format-negotiation code changes the same channel's write format concurrently (always under the channel lock), so the re-check could observe a different format and wrongly reject a valid sound file with: Unable to open beep (format (alaw)): No such file or directory Because the reader never took the channel lock, the set and the re-check were two separate critical sections with the lock dropped in between. Hold the channel lock across both the write-format set and the filehelper(ACTION_OPEN) re-check so the two accesses share a common lock. Confirmed with ThreadSanitizer: the data race on the channel write format no longer appears and the intermittent warning no longer reproduces. Resolves: asterisk#1623
github-actions
Bot
added
pr-submit-testing-in-progress
pr-submit-tests-passed
and removed
pr-submit-testing-in-progress
labels
|
Workflow Check completed successfully |
Contributor
Author
|
cherry-pick-to: 20 |
github-actions
Bot
removed
the
has-pr-checklist
Contributor
Author
|
I would appreciate any feedback on the potential downsides of holding the channel lock across the "filehelper" call. |
Member
|
It should be safe. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
openstream_internal() set the channel write format under the channel lock, released the lock, then re-checked that format in filehelper() (ACTION_OPEN) while holding only the formats RWLIST. The bridging and format-negotiation code changes the same channel's write format concurrently (always under the channel lock), so the re-check could observe a different format and wrongly reject a valid sound file with:
Unable to open beep (format (alaw)): No such file or directory
Because the reader never took the channel lock, the set and the re-check were two separate critical sections with the lock dropped in between.
Hold the channel lock across both the write-format set and the filehelper(ACTION_OPEN) re-check so the two accesses share a common lock.
Confirmed with ThreadSanitizer: the data race on the channel write format no longer appears and the intermittent warning no longer reproduces.
Resolves: #1623