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

[Utkarsh Rai]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201101/cc60fa85/attachment.html>