Design issues with thread-stack isolation/sharing.

[Utkarsh Rai]

On Sat, Aug 1, 2020 at 10:51 PM Gedare Bloom <gedare at rtems.org> wrote:

> 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.
>

Ok, but this would mean that we can only share a set number of stacks with
each thread?


>
> > 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.
>

I agree it's just that it is extra work and maybe I was being lazy :).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200802/0b927fcc/attachment.html>