kernel/mempool: Handle transient failure condition #7934
Merged
Conversation
This file contains 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
The sys_mem_pool implementation has a subtle error case where it detected a simultaneous allocation after having released the lock, in which case exactly one of the racing allocators will return with -EAGAIN (the other one suceeds of course). I documented this condition at the lower level, but forgot to actually handle it at the k_mem_pool level where we want to retry once before going to sleep, as it doesn't generally represent an empty heap. It got caught by code auditing in: zephyrproject-rtos#6757 (Full disclosure: I tested this by whiteboxing the first failure. I wasn't able to put together a rig to reliably exercise the actual race.) This patch also fixes a noop thinko in the return logic in the same function, which contained: (ret == -EAGAIN) || (ret && ret != -ENOMEM) The first term is needless and implied by the second. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Codecov Report
@@ Coverage Diff @@
## master #7934 +/- ##
==========================================
- Coverage 55.03% 55.02% -0.01%
==========================================
Files 483 483
Lines 53966 53971 +5
Branches 10490 10493 +3
==========================================
+ Hits 29698 29699 +1
- Misses 19992 19993 +1
- Partials 4276 4279 +3
Continue to review full report at Codecov.
|
andrewboie
approved these changes
May 25, 2018
lpereira
reviewed
May 25, 2018
| if (ret == -EAGAIN) { | ||
| ret = -ENOMEM; | ||
| } | ||
|
|
||
| block->id.pool = pool_id(p); | ||
| block->id.level = level_num; | ||
| block->id.block = block_num; |
There was a problem hiding this comment.
If you move these assignments before the previous if statement, a return -ENOMEM can be performed instead of setting ret -- should shave off a few bytes from the if statement below.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The sys_mem_pool implementation has a subtle error case where it
detected a simultaneous allocation after having released the lock, in
which case exactly one of the racing allocators will return with
-EAGAIN (the other one suceeds of course).
I documented this condition at the lower level, but forgot to actually
handle it at the k_mem_pool level where we want to retry once before
going to sleep, as it doesn't generally represent an empty heap. It
got caught by code auditing in:
Fixes #6757
(Full disclosure: I tested this by whiteboxing the first failure. I
wasn't able to put together a rig to reliably exercise the actual
race.)
This patch also fixes a noop thinko in the return logic in the same
function, which contained:
(ret == -EAGAIN) || (ret && ret != -ENOMEM)
The first term is needless and implied by the second.
Signed-off-by: Andy Ross andrew.j.ross@intel.com