On Tue, Jan 26, 2021 at 9:33 PM Gedare Bloom <ged...@rtems.org> wrote:
> > > On Tue, Jan 26, 2021 at 8:24 AM Sebastian Huber < > sebastian.hu...@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? > Yes. > > 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). > Ok, I will start with the simpler solution. > -Gedare >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
