pussuw edited a comment on pull request #5731: URL: https://github.com/apache/incubator-nuttx/pull/5731#issuecomment-1080610588
Thank you for your response, yes it is clear that xcp.regs is still in kernel memory and is addressable. However, the memory for the context itself exists in MMU mapped memory only if I'm right. As `tcb->stack_alloc_ptr = kumm_malloc(stack_size); `uses the userspace heap allocator which works with virtual addresses that exist in the user task's own memory. Obviously the mapping exists for the kernel as well, when the task is in execution. What I'm concerned about is that calling `(void)group_addrenv(nexttcb);` prior to the context switch changes the MMU mappings already, and the address environment that is used to store the task that is being preempted is not in place any more. So where does e.g. arm_switchcontext(a,b) actually save the task's context (the task that is removed from execution) ? It pushes it to the stack, but to me it will be the new task's address environment (task that will continue) and the old register set is saved into task b:s stack instead of task a:s stack. Unless I'm totally missing something here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
