Design issues with thread-stack isolation/sharing.

[Gedare Bloom]

On Sat, Aug 1, 2020 at 10:38 AM Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:
>
> This thread is an attempt to consolidate and resolve all the issues that have been raised related to my patches- 1. https://lists.rtems.org/pipermail/devel/2020-July/060675.html and 2. https://lists.rtems.org/pipermail/devel/2020-July/061056.html. I intend to first resolve all the issues through this thread( and probably convert this into a blog-post ), before making any further changes.
>
> 1. Stack address name that needs to be passed to shm_open() - This was briefly discussed here, and I believe the reason we still have issues with this is because of my incorrect interpretation of what was suggested. My idea was that we need to assign a name like "/taskfs/pid" to each stack address on the creation of the thread. On looking around further, I realize we can have the stack address name the same as the thread name.
>
ok. the /taskfs idea was more of a longer-term concept. I think it
would require possibly an entire GSoC itself. It'd be nice though :)

> 2. Switching out shared stacks- In my current implementation, removing protected stacks is done through assembly code but the '_Stackprotection_Context_switch' which switches out the shared stack is difficult to implement in assembly. But we need to integrate the shared stack switching in the context switching code as we don't have access to executing thread attributes anywhere else.
>
I think the real problem here is that your code to switch stacks is
too complicated. It would certainly be folly to try to implement
linked list processing in assembly of the context switch, but you
shouldn't need to be walking a linked list anyway. There are simpler
solutions that would work just as well, including replacing the entire
address space (e.g., switching the page table base register) or using
an array to store the shared stack addresses and just iterating the
array.

> 3. Integration of the 'Stackprotection_attr' structure with the thread and stack control structure - The integration is a pretty straightforward task, the difficulty lies in handling the attribute offset in the assembly code, whereas having the 'Stackprotection_attr'  just after the context control attribute in the thread control structure makes handling the offset relatively easy.
>
The Stack_Control is embedded already, you just need to calculate the
location of Thread_Control.Start.Initial_stack first, and then offset
within that structure.