arch: arm: userspace: don't subtract MPU guard from top of stack

[ioannisg]

ip register holds the stack_info.size (it is passed as argument
into z_arch_user_mode_enter(.)). We trust that the value of
stack_info.size contains the accurate size of the writable
stack buffer, above stack_info.start (as specified in kernel.h).
Therefore, we do not need to subtract any bytes for the MPU
stack guard. This allows us to clean-up one more occurrence of
CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT in userspace.S.

Signed-off-by: Ioannis Glaropoulos [email protected]

[ioannisg]

Yet another removal of the unwanted CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT from arch/arm code. This seems to be actually a minor bug, eating up 32 bytes from the stack of a user thread.

[ioannisg]

@andrewboie please, take a quick look; do you think we should back-port this one?

[wentongwu]

Yet another removal of the unwanted CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT from arch/arm code. This seems to be actually a minor bug, eating up 32 bytes from the stack of a user thread.

Yes, the mpu guard for thread stack has already been take care in z_new_thread when thread is setup.

[wentongwu]

The stack_info is under CONFIG_THREAD_STACK_INFO, we can see this in function z_new_thread_init, but I see several places using stack_info directly without CONFIG_THREAD_STACK_INFO wrapped like function z_arch_user_mode_enter, do I miss something?
@ioannisg

[ioannisg]

The stack_info is under CONFIG_THREAD_STACK_INFO, we can see this in function z_new_thread_init, but I see several places using stack_info directly without CONFIG_THREAD_STACK_INFO wrapped like function z_arch_user_mode_enter, do I miss something?
@ioannisg

@wentongwu For ARM, THREAD_STACK_INFO is selected under two cases

• build with MPU support (ARM_MPU)
• build with BUILTIN_STACK_GUARD support (ARMV8-M), not necessarily with MPU support.

If you see it being used outside these two cases, this is a (serious) bug.

[wentongwu]

The stack_info is under CONFIG_THREAD_STACK_INFO, we can see this in function z_new_thread_init, but I see several places using stack_info directly without CONFIG_THREAD_STACK_INFO wrapped like function z_arch_user_mode_enter, do I miss something?
@ioannisg

@wentongwu For ARM, THREAD_STACK_INFO is selected under two cases

* build with MPU support (ARM_MPU)

* build with BUILTIN_STACK_GUARD support (ARMV8-M), not necessarily with MPU support.

If you see it being used outside these two cases, this is a (serious) bug.

OK, thanks for the info.

[ioannisg]

@andrewboie could you review this minor patch, too?