search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.84k stars 6.6k forks source link

ARM should only use CONFIG_GEN_PRIV_STACKS if the MPU requires it #24048

Open andrewboie opened 4 years ago

andrewboie commented 4 years ago

Describe the bug Currently we are generating separate privilege mode stacks for all ARM targets, even if the MPU does not require it.

Expected behavior We should continue to select CONFIG_GEN_PRIV_STACKS if and only if CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT is set.

Boards that don't require this can put everything in the stack object, for example:

CONFIG_USERSPACE=y
CONFIG_MPU_STACK_GUARD=y
+------------+-----------------+-----------------------------+
| guard area | privilege stack | thread stack                |
+------------+-----------------+-----------------------------+

CONFIG_USERSPACE=n
CONFIG_MPU_STACK_GUARD=y
+------------+----------------------------+
| guard area | thread stack               |
+------------+----------------------------+

CONFIG_USERSPACE=y
CONFIG_MPU_STACK_GUARD=n
+-----------------+--------------------------------+
| privilege stack | thread stack                   |
+-----------------+--------------------------------+

CONFIG_USERSPACE=n
CONFIG_MPU_STACK_GUARD=n
+-----------------------------------------+
| thread stack                            |
+-----------------------------------------+

Impact Low. The overhead of the separate privilege mode stacks is very little. It used to be much worse when we had a separate gperf table for them. However, this still can waste memory if MPU guards are in use since the guard has to either be placed at the beginning of the privilege stack or the beginning of the stack object depending on what mode the thread is running in, requiring carve-outs or wasted space.

By only using this mechanism on CPUs that require it, it will help us later down the road to remove this mechanism when we no longer support these MPUs.

zephyrbot commented 9 months ago

Hi @dcpleung,

This issue, marked as an Enhancement, was opened a while ago and did not get any traction. It was just assigned to you based on the labels. If you don't consider yourself the right person to address this issue, please re-assing it to the right person.

Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.

@andrewboie you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you.

Thanks!