sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

sched/release_tcb: Do not release stack for user processes here

Browse Source 
The user stack is dependent on the user address environment. As the
process exits, this address environment is destroyed anyway, so the
stack does not need to be released separately.

There is also an issue with this when the process exits via exit(). The
problem is that the task group is released prior to this "up_release_stack()"
call along with the address environment, and trying to free the memory
either causes an immediate crash (no valid addrenv), or frees memory into
another process' heap (addrenv from a different process).

Signed-off-by: Ville Juven <ville.juven@unikie.com>
This commit is contained in:
Ville Juven 2022-12-13 16:45:12 +02:00 committed by Xiang Xiao
parent e1561f8512
commit 1a67dc7c68
1 changed files with 16 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
sched/sched/sched_releasetcb.c
View File

@ -126,7 +126,22 @@ int nxsched_release_tcb(FAR struct tcb_s *tcb, uint8_t ttype)
if (tcb->stack_alloc_ptr)
{
up_release_stack(tcb, ttype);
#ifdef CONFIG_BUILD_KERNEL
/* If the exiting thread is not a kernel thread, then it has an
* address environment. Don't bother to release the stack memory
* in this case... There is no point since the memory lies in the
* user memory region that will be destroyed anyway (and the
* address environment has probably already been destroyed at
* this point.. so we would crash if we even tried it). But if
* this is a privileged group, when we still have to release the
* memory using the kernel allocator.
*/
if (ttype == TCB_FLAG_TTYPE_KERNEL)
#endif
{
up_release_stack(tcb, ttype);
}
}
#ifdef CONFIG_PIC