On Sun, Aug 16, 2020 at 9:18 PM Gedare Bloom <ged...@rtems.org> wrote:
> On Sat, Aug 15, 2020 at 9:03 PM Utkarsh Rai <utkarsh.ra...@gmail.com> > wrote: > > > > > > > > On Sun, Aug 16, 2020 at 6:12 AM Utkarsh Rai <utkarsh.ra...@gmail.com> > wrote: > >> > >> > >> > >> On Sat, Aug 15, 2020 at 7:26 PM Gedare Bloom <ged...@rtems.org> wrote: > >>> > >>> On Sat, Aug 15, 2020 at 6:26 AM Utkarsh Rai <utkarsh.ra...@gmail.com> > wrote: > >>> > > >>> > > >>> > On Thu, Aug 13, 2020 at 5:10 AM Utkarsh Rai <utkarsh.ra...@gmail.com> > wrote: > >>> >> > >>> >> Thanks, I'll check them out. > >>> >> > >>> >> On Thu, Aug 13, 2020 at 12:56 AM Gedare Bloom <ged...@rtems.org> > wrote: > >>> >>> > >>> >>> On Wed, Aug 12, 2020 at 11:33 AM Utkarsh Rai < > utkarsh.ra...@gmail.com> wrote: > >>> >>> > > >>> >>> > Hello, > >>> >>> > I have been testing my code for thread stack isolation against > various tests( Some written by me, and remaining already present). One of > the limitations that I have found is that I encounter fatal errors whenever > a context switch takes place through an ISR. Can you please explain how the > context switching procedure works when an interrupt occurs. When I use gdb > for stepping through the code it asynchronously moves to context switching > code from the executing thread( for example psx16 test). > >>> >>> > For thread stack protection, the part that deals with context > switching simply 'sets 'the memory entries of the heir stack and 'unsets' > that of the executing stack. > >>> >>> > >>> >>> There are two issues to start: interrupt stacks and dispatching > from an ISR. > >>> >>> > >>> >>> I think you can start by reading some of the documentation: > >>> >>> > https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#processing-an-interrupt > >>> >>> > >>> >>> > https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#dispatching-tasks > >>> >>> > >>> >>> > https://docs.rtems.org/branches/master/c-user/config/general.html#configure-interrupt-stack-size > >>> >>> > >>> >>> > https://docs.rtems.org/branches/master/cpu-supplement/port.html#interrupt-processing > >>> >>> > >>> >>> You can also find some material in rtems-docs.git/porting -- I > don't > >>> >>> know where that gets generated. > >>> >>> > >>> >>> Continue to ask questions, and writing blog posts. > >>> > > >>> > > >>> > So after going through the materials, I was able to understand how > an ISR is registered, ISR stack initialization. What is still not clear to > me is what are the differences between dispatching a task in ISR different > and a normal context-switch? > >>> > > >>> > For example the psxsignal06 test, we wait for a signal here, on > setting the breakpoint at the context switch code (cpu_asm.S), after this > line, I find that the heir context stack is the ISR stack. The next thread > is dispatched from this ISR but as soon as I unset the memory attributes of > the ISR stack I get a fatal error. One possible reason is that the ISR > stack is not page aligned and unsettling its attributes unsets nearby > memory regions. Is there something else that I am missing? > >>> > > >>> what else is on the same page as the ISR stack? > >>> > >> > >> The idle thread stack is between 0x202e40 to 0x203e40 and the ISR stack > is between 0x203e40 to 0x204e40. So when we unset the memory for the ISR it > unsets between 0x203000 to 0x205000, I think this may be the problem. > >> > >> > >>> > >>> Not quite related, you'll need to also make sure to map the ISR stack > >>> back in during ISR Handling, before using it. > >> > >> > >> When the ISR gets called for the first time, it already has R/W > permission and for subsequent context switches it's memory entry is > accordingly set/unset. > > > > > > The idle thread stack and the ISR stack are placed at these addresses > with the BSP specific linker script as "rtemsstack.idle" and > "rtemsstack.interrupt". So to make them page-aligned we may have to make > changes in the lnker script. > > Give it a try. It should be relatively easy to hack in a couple of > alignments. > > We can discuss later the correctness of that. > Ok, I will report how it goes.
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel