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

refactor: Always fail hard on allocation failure in tox_events. #2264

Closed
wants to merge 1 commit into from

Conversation

iphydf
Copy link
Member

@iphydf iphydf commented Apr 7, 2022

Partial success is not much more helpful, because at the point of
allocation failure, the client will probably need to shut down or drop
caches to free memory and request re-sends from friends. Those requests
don't exist in current Tox messages, but future history-sync based
messaging would be able to handle temporary allocation failures.

Also in the future, a single iteration will have a limited number of
events it can process at a time, configurable through Tox_Options. This
way there is an upper limit on how much memory an events iteration can
allocate. This will be necessary for security (avoiding Resource
Exhaustion Attacks, which the current events system is somewhat
vulnerable to).


This change is Reviewable

@iphydf iphydf added this to the v0.2.18 milestone Apr 7, 2022
@auto-add-label auto-add-label bot added the refactor Refactoring production code, eg. renaming a variable, not affecting semantics label Apr 7, 2022
@iphydf iphydf force-pushed the always-fail-hard branch 2 times, most recently from 600ae22 to fb2c94b Compare April 7, 2022 21:21
@codecov
Copy link

codecov bot commented Apr 7, 2022

Codecov Report

Merging #2264 (f2bb086) into master (50094b7) will increase coverage by 0.01%.
The diff coverage is 100.00%.

❗ Current head f2bb086 differs from pull request most recent head af2517b. Consider uploading reports for the commit af2517b to get more accurate results

@@            Coverage Diff             @@
##           master    #2264      +/-   ##
==========================================
+ Coverage   78.92%   78.93%   +0.01%     
==========================================
  Files         127      127              
  Lines       24063    24001      -62     
==========================================
- Hits        18992    18946      -46     
+ Misses       5071     5055      -16     
Impacted Files Coverage Δ
auto_tests/tox_dispatch_test.c 97.36% <100.00%> (ø)
auto_tests/tox_events_test.c 96.87% <100.00%> (ø)
toxcore/tox_events.c 78.43% <100.00%> (ø)
toxcore/TCP_client.c 83.13% <0.00%> (-0.94%) ⬇️
toxcore/network.c 86.77% <0.00%> (-0.63%) ⬇️
toxav/msi.c 64.39% <0.00%> (-0.35%) ⬇️
toxcore/util.c 57.89% <0.00%> (-0.17%) ⬇️
toxcore/net_crypto.c 87.36% <0.00%> (-0.08%) ⬇️
toxcore/onion_client.c 90.61% <0.00%> (-0.04%) ⬇️
toxcore/TCP_server.c 78.77% <0.00%> (+0.18%) ⬆️
... and 6 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 50094b7...af2517b. Read the comment docs.

@iphydf iphydf modified the milestones: v0.2.18, v0.2.19 Apr 8, 2022
@iphydf iphydf modified the milestones: v0.2.19, v0.2.20 Apr 18, 2022
Partial success is not much more helpful, because at the point of
allocation failure, the client will probably need to shut down or drop
caches to free memory and request re-sends from friends. Those requests
don't exist in current Tox messages, but future history-sync based
messaging would be able to handle temporary allocation failures.

Also in the future, a single iteration will have a limited number of
events it can process at a time, configurable through Tox_Options. This
way there is an upper limit on how much memory an events iteration can
allocate. This will be necessary for security (avoiding Resource
Exhaustion Attacks, which the current events system is somewhat
vulnerable to).
@iphydf iphydf closed this Dec 9, 2023
@iphydf iphydf deleted the always-fail-hard branch December 9, 2023 11:54
@iphydf iphydf modified the milestones: v0.2.20, v0.2.19 Dec 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactor Refactoring production code, eg. renaming a variable, not affecting semantics
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant