Fix newlib malloc thread safety issue #35227
Merged
Conversation
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
This commit adds a lock implementation for the newlib heap memory management functions (`malloc` and `free`). The `__malloc_lock` and `__malloc_unlock` functions are called by the newlib `malloc` and `free` functions to synchronise access to the heap region. Without this lock, making use of the `malloc` and `free` functions from multiple threads will result in the corruption of the heap region. Signed-off-by: Stephanos Ioannidis <[email protected]>
This commit removes the lock inside the newlib internal `_sbrk` function, which is called by `malloc` when additional heap memory is needed. This lock is no longer required because any calls to the `malloc` function are synchronised by the `__malloc_lock` and `__malloc_unlock` functions. Signed-off-by: Stephanos Ioannidis <[email protected]>
github-actions
bot
added
area: C Library
stephanosio
force-pushed
the
newlib_ts_test
branch
2 times, most recently
from
ae04595 to
973f918
Compare
Member
Author
|
Please ignore checkpatch warning. It's wrong. |
This commit adds a new test to verify the thread safety of the C standard functions provided by newlib. Only the memory management functions (malloc and free) are tested at this time; this test will be further extended in the future, to verify the thread safety and re-entrancy of all supported newlib functions. Signed-off-by: Stephanos Ioannidis <[email protected]>
stephanosio
force-pushed
the
newlib_ts_test
branch
from
973f918 to
36f64da
Compare
stephanosio
added
bug
andyross
approved these changes
May 12, 2021
| } | ||
| __weak FUNC_ALIAS(_sbrk, sbrk, void *); | ||
|
|
||
| static LIBC_DATA SYS_MUTEX_DEFINE(heap_mutex); |
Contributor
There was a problem hiding this comment.
When CONFIG_USERSPACE=n, making this a spinlock would be much smaller/faster. But they I guess someday we'll get around to implementing a futex backend for sys_mutex which would have the same property.
galak
approved these changes
May 13, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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.
This series includes a set of patches to fix the thread safety-related issue when calling the
mallocandfreefunctions from multiple threads, as well as a new test to validate the thread safety issue.Before
After
A more comprehensive series addressing the thread safety and re-entrancy issues for all newlib functions will be submitted in the future -- this series is meant to address only the most critical aspect (i.e. memory management) of the underlying problems in a timely manner.
Related to #21519 and #21518