Fatal exceptions on context-switching for more than two isolated threads

[Gedare Bloom]

On Sun, Nov 1, 2020 at 9:49 AM Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:
>
>
>
>
> On Fri, Oct 23, 2020 at 10:28 PM Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:
>>
>>
>>
>> On Fri, Oct 23, 2020 at 9:57 PM Gedare Bloom <gedare at rtems.org> wrote:
>>>
>>> On Fri, Oct 23, 2020 at 9:37 AM Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:
>>> >
>>> >
>>> >
>>> > On Thu, Oct 22, 2020 at 11:23 PM Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
>>> >>
>>> >> On 22/10/2020 02:40, Utkarsh Rai wrote:
>>> >>
>>> >> > Hello, this thread has gone a bit cold over the last few weeks, due to
>>> >> > my engagement in the university tests.  I have provided a debug trace
>>> >> > for the issue.  The reason for fatal exceptions is the fact that while
>>> >> > iterating over the chain of user extensions we access a node whose
>>> >> > memory location has been set to NO-ACCESS during the context switch.
>>> >> > Is there any work-around to this?
>>> >>
>>> >> The option is to move the User_extensions_Iterator storage out of the
>>> >> stack to Thread_Control and Per_CPU_Control.
>>> >>
>>> >
>>> > Does this mean that I should add User_extensions_Iterator field in the Thread_Control structure for the case
>>> > when we enable thread stack protection?
>>> >
>>>
>>> You need to dig in a little bit more. From what I understand, there is
>>> the last_user_extensions_iterator field of the TCB. That is probably
>>> where you are running into some trouble. See
>>> score/src/userextiterate.c :193 where this field gets assigned to a
>>> stack-local variable.
>>
>>
>> I get an exception just before this when _Chain_Iterator_initialize() is called, the reason though is the same, accessing
>> a stack-local variable of a switched out thread. From what I could understand,  the 'iter' variable(corresponding to the User_extensions_Iterator type)
>> is the only stack-local variable of a switched out thread that is accessed from a different thread.
>>
>>>
>>> Then, you can't walk this chain when the thread
>>> is out of context.
>>>
>>> >>
>>> >> --
>>> >> Sebastian Huber, embedded brains GmbH
>>> >>
>>> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>>> >> Phone   : +49 89 189 47 41-16
>>> >> Fax     : +49 89 189 47 41-09
>>> >> E-Mail  : sebastian.huber at embedded-brains.de
>>> >> PGP     : Public key available on request.
>>> >>
>>> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>> >>
>
>
>
>  Based on the above suggestions I tried to move the User_extensions_Iterator storage to the TCB by adding a new field to the structure, but that did not compile(userextimpl.h is not included with thread.h because of cyclic dependency).
> This made me try out a naive hack, I defined a structure similar to the User_extensions_Iterator and then added the field to the TCB. The next problem that I faced was during the creation of the idle thread. Since an idle thread is created during system
> initialization, the 'executing' pointer pointing the TCB is null, and hence referencing to the iterator placed in the TCB for the idle thread fails. This was resolved by separating the cases for an idle thread and other threads. After that I was able to successfully isolate more than two thread stacks.
> Can you please suggest a more acceptable approach for resolving this issue?
>

At a high level the approach you took makes sense. You have moved the
user extensions to the TCB, and then avoid accessing it in case the
TCB is null (i.e., the initial context switch). I'd need to see the
code to make any further critical analysis. But it sounds acceptable
to me.