ARM: fix TLS pointer issue (1.14 branch)

[andrewboie]

arm: fix stack size accounting

On ARM Cortex-M, which enforces MPU power-of-two alignment,
the memory for stack guards is 'carved-out' of the stack buffer,
and not reserved permanently.

However, the Z_ARCH_THREAD_STACK_BUFFER and
Z_ARCH_THREAD_STACK_SIZEOF implementations were adding/subtracting
the guard size, which is incorrect for carved-out space. This can
only be done if the space is permanently reserved.

Fix this so that these APIs work correctly in the carve-out case.
Adjust thread->stack_info values on transition to user mode correctly.

See: #25635

Signed-off-by: Andrew Boie andrew.p.boie@intel.com

[andrewboie]

This is fixed in master branch by #24714 but I wanted a more targeted fix to backport to 1.14.

This needs HW testing on frdm-k64f (or some other board with the custom NXP MPU)

[ioannisg]

Seems to me you have changed the semantics of Z_ARCH_THREAD_STACK_BUFFER and Z_THREAD_STACK_SIZEOF

Currently:

• Z_ARCH_THREAD_STACK_BUFFER points to the start of the available thread stack, i.e. after the MPU guard (if that one exists).
• Z_ARCH_THREAD_STACK_SIZEOF is the size of the stack available for the thread, i.e. after subtracting the MPU guard (if that one exists).

To facilitate review, pls, explain what you intend to reflect with the macros:
Z_ARCH_THREAD_STACK_BUFFER and Z_ARCH_THREAD_STACK_SIZEOF, then I 'll take a second look.

[andrewboie]

Z_ARCH_THREAD_STACK_BUFFER points to the start of the available thread stack, i.e. after the MPU guard (if that one exists).

This a the problem here. You cannot do this if the guard is "carved out" because you don't know whether the thread is running in user mode or not.

If the thread is running in user mode, there is no guard. The entire stack object is sized to a power of two and the entire stack object is available to the user.

ARCH_THREAD_STACK_BUFFER() can only work properly if it skips permanently reserved memory. Not a guard that may or may not be there depending on what mode the thread is running in. You can't have a constant definition for something that changes at runtime.

ARCH_THREAD_STACK_SIZEOF is the size of the stack available for the thread, i.e. after subtracting the MPU guard (if that one exists).

This was changed for the same reason as ARCH_THREAD_STACK_BUFFER for power-of-two systems: it should only take into account permanently reserved space. Not transient guard memory.

What you are thinking of is actually tracked in thread->stack_info.
thread->stack_info is supposed to accurately reflect the accessible part of the thread stack buffer, minus any memory currently used for reserved data or guard memory. It gets updated when threads change state, such as dropping to user node.

There were several inconsistencies in implementation and semantics for all of this between X86, ARC, and ARM. I have rewritten all of this in #24714 so that it finally is the same everywhere. I did not want to back port all of that to 1.14.

[andrewboie]

@ioannisg I looked at your patch against master and it is less invasive, which is desirable for 1.14 -- this PR pulls in a bit too much stuff from #24714 to acheive its goals.

I'm going to backport your fix instead to touch the code as little as possible. Updated PR coming.

[ioannisg]

Approving the fix and the test.

I'd like to have a full run all -userspace tests for e.g. sam_e70_xplained before merging this to the LTS

[andrewboie]

@ioannisg agreed. Would like some testing on frdm_k64f too since the NXP MPU isn't under emulation.

I have a board but have been having trouble flashing it. I am going to fiddle with it more this afternoon.

I also have a sam_e70 board, I'll give that a go too.

[ioannisg]

I can do all this for you @andrewboie. By the way, although I am fine with testing it on nxp mpu, I find it less important since this workaround does not apply to the nxp mph as far as I remember. Nxp mpu doesn't require power of 2 size alignment

[andrewboie]

I can do all this for you @andrewboie. By the way, although I am fine with testing it on nxp mpu, I find it less important since this workaround does not apply to the nxp mph as far as I remember. Nxp mpu doesn't require power of 2 size alignment

Thanks appreciate it!
You're right, NXP should be unchanged with this PR.

[ioannisg]

Testing on sam_e70_xplained and frdm_k64f:

• tests/kernel
• tests/lib
• tests/benchmarks
• tests/cmsis_rtos_v1, v2

tests are passing