-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
rewrite the frame sorter #2561
rewrite the frame sorter #2561
Conversation
0346e79
to
3a08979
Compare
Codecov Report
@@ Coverage Diff @@
## master #2561 +/- ##
==========================================
+ Coverage 86.17% 86.22% +0.05%
==========================================
Files 122 122
Lines 9550 9584 +34
==========================================
+ Hits 8229 8263 +34
- Misses 983 984 +1
+ Partials 338 337 -1
Continue to review full report at Codecov.
|
3a08979
to
39fe927
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.
LGTM, but it's very difficult to read the diff here. For the future, it would be helpful if you outlined the major changes in the commit message :)
return gap.Prev(), false | ||
} | ||
} | ||
panic("no gap found") |
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.
Could an attacker trigger this panic by sending us a frame with offset = MaxByteCount?
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.
We'd only read that frame if we read everything before MaxByteCount
. Also, we'd trigger a flow control error before even enqueuing such a frame.
Fixes #2533, fixes #2544, fixes #2545. Fixes #2521, assuming that this error was a result of the race condition.
Adds a bunch of new test cases, including a randomized test, which would have caught the bugs.