Design issues with thread-stack isolation/sharing.

[Gedare Bloom]

On Sun, Aug 2, 2020 at 5:46 AM Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:
>
>
>
> 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?
>

Perhaps. You might be able to use an extendable array if the number of
shared stacks is configurable. This again goes into the problem that
configuration hasn't been solved yet.

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

Maybe. Sometimes it is better to pay now than later though.