pussuw commented on issue #8917: URL: https://github.com/apache/nuttx/issues/8917#issuecomment-1513086554
I'll move the discussion back here to avoid spamming the mailing list. My understanding of the semaphore handling logic increases bit by bit and thus far I have found the following: - `tcb->waitobj` is user by the system scheduler to implement the `TSTATE_WAIT_SEM`-list, it accesses `dq_queue_t waitlist;` - This basically means that whenever a semaphore is set into `tcb->waitobj` -> **the memory must be accessible to the kernel, even from other processes** and this access has to be deterministic (preferably also fast). - Adding temporary mappings to (or addrenv switch) into `nxsem_wait_irq` does fix the watchdog interrupt and signal dispatch cases, but not the case mentioned above -> **doing any temp mappings in `nxsem_wait_irq` is simply futile**. - `nxsem_canceled` is called from `nxsem_wait_irq`, this accesses the priority inheritance list `tcb->holdsem`, which also holds a reference to the semaphore via `holdsem->sem`, and this points to user memory also. - This means that not only does the semaphore access not work, priority inheritance is also broken with CONFIG_BUILD_KERNEL. -> **the pointer in `tcb->holdsem->sem` must also be accessible to the kernel in a deterministic (preferably also fast) manner**. Implementing dynamic mappings for the semaphore works wonderfully when the semaphore structure fits inside a single page. When it crosses a page boundary the problems start. In this case we lose all measures of deterministic behavior, because we need to: - Do two table walks to find the physical pages -> this is O(1) - Find a virtual memory area where the mapping fits -> this is O(n) orO(log(n)) at best - Map the pages into kernel addressable memory -> this is O(1) - Mark the mappings into a list, where they can be found later -> this is O(1) When the semaphore is taken, the process marks itself as the holder. - The mapping needs to exist until the the semaphore is released, because only at this point the holder list can be updated. This means the mapping can live for a LONG time. - When the semaphore is released, the virtual memory must be unmapped. - This means the mapping list must be traversed to find whether a mapping really exists -> this is O(n) - Why do we need a list? Because semaphores are used by the kernel itself too, these don't need to be dynamically mapped. So to me it seems like mapping the semaphore to kernel memory won't fix anything. Unless there is some obvious solution I'm missing. Please correct me if I'm typing nonsense, as I'm still trying to grasp the big picture. -- 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
