K_THREAD_STACK_BUFFER() is broken #14766
Assignees
Labels
area: Memory Protection
bug
The issue is a bug, or the PR is fixing a bug
priority: low
Low impact/importance bug
Comments
andrewboie
added
bug
|
what are the plans for this issue? Is it going to be fixed for 1.14 release? |
|
Implementation is in progress. |
andrewboie
added
priority: low
|
Setting to low, in current code this may not reveal the true stack buffer, but does not point to memory outside of the stack object. |
andrewboie
pushed a commit
to andrewboie/zephyr
that referenced
this issue
Apr 5, 2019
This macro is slated for complete removal, as it's not possible on arches with an MPU stack guard to know the true buffer bounds without also knowing the runtime state of its associated thread. As removing this completely would be invasive to where we are in the 1.14 release, demote to a private kernel Z_ API instead. The current way that the macro is being used internally will not cause any undue harm, we just don't want any external code depending on it. The final work to remove this (and overhaul stack specification in general) will take place in 1.15 in the context of zephyrproject-rtos#14269 Fixes: zephyrproject-rtos#14766 Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
nashif
pushed a commit
that referenced
this issue
Apr 5, 2019
This macro is slated for complete removal, as it's not possible on arches with an MPU stack guard to know the true buffer bounds without also knowing the runtime state of its associated thread. As removing this completely would be invasive to where we are in the 1.14 release, demote to a private kernel Z_ API instead. The current way that the macro is being used internally will not cause any undue harm, we just don't want any external code depending on it. The final work to remove this (and overhaul stack specification in general) will take place in 1.15 in the context of #14269 Fixes: #14766 Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This macro has a design flaw: it assumes that the offset to the stack buffer, within the stack object, is constant.
However, on ARC this offset changes depending on whether the stack is being used in supervisor or user mode. There are no reverse references to the thread in the stack object (nor is it possible to add one); this API is broken by design.
This API needs to be removed; if someone needs to know the bounds of an in-use stack, this information is available in the thread struct anyway.
The text was updated successfully, but these errors were encountered: