xiaoxiang781216 commented on pull request #5731: URL: https://github.com/apache/incubator-nuttx/pull/5731#issuecomment-1080654327
> 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. > Yes, I think so. > 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. call group_addrenv here is too early, even without @no1wudi 's change, it still can't work as expect, because the current stack is swapped out. > 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. > Since the similar code also exist on ARM, @anchao will try to provide a patch fixing this issue. -- 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
