Report on failing tests with thread stack protection and their resolution.

[Gedare Bloom]

On Tue, Jan 26, 2021 at 8:24 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 23/01/2021 07:27, Utkarsh Rai wrote:
>
> > The issue that remains is of User extension iterators, in particular
> > of nested iterators. My idea is to disable memory protection in places
> > during iteration where inter-stack access takes place.  The problem is
> > determining the region for which memory protection needs to be
> > disabled. One way to get around this would be by disabling memory
> > protection for all the stacks, in a blanket-based manner.
>
> I used this approach for a Nios II system with a thread stack
> protection. We trust the operating system, so this approach should be fine.
>
> +1 that looks good for an initial solution.
[...]


>
> > The other possibility is to access the last blocked thread and disable
> > memory protection just for the stack of this thread (as inter-stack
> > access of the previously blocked thread takes place during iteration).
> > How to get access to the queue of blocked threads? And is this method
> > feasible?
> The system doesn't know the last blocked thread currently. I am not sure
> if knowing the last blocked thread helps you here.
>
>
If I recall right, there are two problems to solve.
1. The user extension iterator code uses thread stacks to manage some of
its data structures. The correct fix would be to rewrite it to use some
workspace regions probably, but this is out of scope. I suspect that this
is the case where the last blocked thread stack is the one that gets used?

2 . The user extensions themselves might touch thread stacks as they run.
This is probably a common case that would need to be resolved like Joel
said, by punting responsibility to the user to disable protection
before/after touching stacks.

The simple solution is to disable/enable around the call to the user
extension iterator, while the slightly more advanced solution is to do that
within any RTEMS-provided extensions that touch the stack. Utkarsh, you
might want to start with the simple solution to get everything working, and
make a plan to do the more advanced solution.

It could be possible that addressing #1 and #2 is appropriate for the
revised GSoC scope (50% as large projects).

-Gedare
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210126/794d127d/attachment.html>