Fix #1449, POSIX implementation honors stack pointer#1450
Merged
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| *-----------------------------------------------------------------*/ | ||
| int32 OS_Posix_InternalTaskCreate_Impl(pthread_t *pthr, osal_priority_t priority, size_t stacksz, | ||
| PthreadFuncPtr_t entry, void *entry_arg) | ||
| int32 OS_Posix_InternalTaskCreate_Impl(pthread_t *pthr, osal_priority_t priority, osal_stackptr_t stackptr, |
Check notice
Code scanning / CodeQL-coding-standard
Function too long
| *-----------------------------------------------------------------*/ | ||
| int32 OS_Posix_InternalTaskCreate_Impl(pthread_t *pthr, osal_priority_t priority, size_t stacksz, | ||
| PthreadFuncPtr_t entry, void *entry_arg) | ||
| int32 OS_Posix_InternalTaskCreate_Impl(pthread_t *pthr, osal_priority_t priority, osal_stackptr_t stackptr, |
Check notice
Code scanning / CodeQL-coding-standard
Long function without assertion
When the OS_TaskCreate() function is called with a non-NULL stack pointer, the POSIX implementation now should use this pointer as intended. Previously it was always allocating a new stack buffer, ignoring the passed-in pointer. NOTE: When using this feature, the caller must use caution to make sure the buffer being passed in is large enough to use as a task stack. Particularly when running under a desktop Linux/Glibc environment, the infrastructure puts a considerably large object on the stack. For example, in the osal-core-tests, the stack size was too small.
jphickey
force-pushed
the
fix-1449-stackptr
branch
from
74503ec to
e0d3d5a
Compare
jphickey
added
the
CCB:Ready
2 tasks
dzbaker
added
CCB:Approved
dzbaker
added a commit
that referenced
this pull request
Feb 22, 2024
Fix #1449, POSIX implementation honors stack pointer
dzbaker
added a commit
to nasa/cFS
that referenced
this pull request
Feb 22, 2024
*Combines:* cFE equuleus-rc1+dev94 osal equuleus-rc1+dev47 to_lab equuleus-rc1+dev42 **Includes:** *cFE* - nasa/cFE#2515 *osal* - nasa/osal#1448 - nasa/osal#1450 *to_lab* - nasa/to_lab#191 Co-authored by: Joseph Hickey <[email protected]> Co-authored by: Avi Weiss <[email protected]>
This was referenced Feb 22, 2024
jphickey
added
the
CCB:Ready
Contributor
Author
|
Ready for [re-]review. Checking further into detail of the RTEMS implementation -- the needed API was only added in the latest development branch (6.x) and is not available on either RTEMS 4.11 nor 5.x. Furthermore, the documentation warns that this is only intended for use with low-level device drivers that have special requirements, and general tasks should not force a stack pointer, as the stack buffers have special requirements for size and alignment. Therefore, with the consideration that we will likely also deprecate/discourage users from specifying a stack buffer due to similar issues on other platforms, the best solution for now is to simply skip this functional test on RTEMS. |
dzbaker
removed
the
CCB:Ready
dzbaker
added a commit
to nasa/cFS
that referenced
this pull request
Feb 29, 2024
*Combines:* cFE equuleus-rc1+dev100 osal equuleus-rc1+dev58 **Includes:** *cFE* - nasa/cFE#2520 *osal* - nasa/osal#1450 Co-authored by: Joseph Hickey <[email protected]>
This was referenced Feb 29, 2024
dzbaker
added a commit
to nasa/cFS
that referenced
this pull request
Feb 29, 2024
*Combines:* cFE equuleus-rc1+dev100 osal equuleus-rc1+dev58 **Includes:** *cFE* - nasa/cFE#2520 *osal* - nasa/osal#1450 Co-authored by: Joseph Hickey <[email protected]>
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
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.
Checklist (Please check before submitting)
Describe the contribution
When the OS_TaskCreate() function is called with a non-NULL stack pointer, the POSIX implementation now should use this pointer as intended. Previously it was always allocating a new stack buffer, ignoring the passed-in pointer.
NOTE: When using this feature, the caller must use caution to make sure the buffer being passed in is large enough to use as a task stack. Particularly when running under a desktop Linux/Glibc environment, the infrastructure puts a considerably large object on the stack. For example, in the osal-core-tests, the stack size was too small.
Fixes #1449
Testing performed
Build and run all tests. Added tests that ensure the stack pointer is being honored as expected.
Expected behavior changes
User-supplied stack buffer will be used on POSIX.
System(s) tested on
Debian
Additional context
This could have negative consequences if the user was assuming RTOS-like behavior (e.g. no thread local storage) and was using very small stack sizes. If the supplied stack size is less than 16k, (or
PTHREAD_STACK_MIN) then the call will now fail, whereas previously it would quietly be made bigger than requested.Contributor Info - All information REQUIRED for consideration of pull request
Joseph Hickey, Vantage Systems, Inc.